Рубрики
Без рубрики

Обреченный Обзор Кода

Обзоры кода должны быть краткими, краткими и целенаправленными. Этот не был ни тем, ни другим но мы соединили наши головы и перевернули все с ног на голову. И с хорошими результатами тоже!

Автор оригинала: Nicolai Parlog.

Есть пара вещей, которые вы должны сделать, чтобы сделать обзоры кода успешными . Главный из них:

  • Держите их краткими (не более 200-400 строк).
  • Держите их короткими (не просматривайте дольше часа).
  • Держите их сосредоточенными (небольшие последовательные приращения)

Это история о том, как я потерпел неудачу во всех этих аккаунтах и как мой приятель по коду (он мой назначенный рецензент на этот месяц—читайте как мы делаем обзоры чтобы узнать, почему мы делаем это таким образом), и я все равно заставил это работать.

Ниспровержение

Вот и я—функция наконец-то была завершена. И с этим осознанием то, что некоторое время скреблось внутри моего черепа, теперь внезапно вырвалось наружу: Вам все равно нужно получить отзыв . Для этого кода. Все это.

А что касается стандартов обзора, то их было очень много! Основной вклад состоял примерно из 2 500 новых линий, распределенных по 30 классам. Кроме того, появилось около 400 различных строк в 25 существующих классах.

От одной мысли о том, чтобы свалить все это на моего кодового приятеля, меня затошнило. Если бы кто-то сделал это со мной, у меня было бы несколько подходящих слов и, возможно, красиво завернутая рысь для них.

Я начал оправдывать то, что сделал: сначала были каникулы, потом я не работал, а потом не было моего приятеля. Вдобавок ко всему, люди продолжали перебивать меня, и я никогда не был в хорошей точке останова, чтобы начать периодический обзор. Проблема была просто слишком большой. И код, очевидно, был правильным!

Бла-бла – бла, лепет виноватых. И это ничего не изменило: я был там—все еще с 3000 строками кода, которые мне нужно было просмотреть.

Из Темноты

Что вы делаете в первую очередь, когда бросаете мяч? Ты признаешься!

Поэтому я сел со своим приятелем по коду, и мы проверили его расписание, чтобы убедиться, что он сможет пройти проверку в разумные сроки. Больше всего на свете мы хотели, чтобы это не превратилось в бесконечную трясину.

После того, как он изучил билет, я дал ему обзор кода на высоком уровне и рассказал, как я все организовал, чтобы мы могли обсудить, как объединить изменения в последовательные обзоры. И вот что я сделал дальше.

Я сел и просмотрел свои 50 или около того коммитов для этой задачи. Тенденция тщательно разделять их по тому, к какому коду они прикасаются, действительно окупилась и оказалась гораздо более важной, чем их размер. На самом деле, некоторые коммиты были довольно большими, но это были те, которые добавили кучу новых классов, которые в совокупности реализуют небольшую функцию. Те, которые касались кода до моей работы, как правило, были очень маленькими, сосредоточенными и не были связаны с новыми материалами.

Прочесывание коммитов заняло у меня около двух часов и привело к девяти отзывам:

  • три довольно больших, охватывающих отдельные аспекты новой функции
  • два средних, которые добавили функциональность к существующим API
  • три небольших, охватывающих незначительные изменения в существующих API
  • в основном несвязанный рефакторинг среднего размера

Каждый обзор содержал вступительный абзац, который соотносил его с другими обзорами.

В качестве дополнительного преимущества и, как это обычно бывает, подробная подготовка привела к некоторой тонкой настройке базового кода и его комментариев.

На Свет

Теперь пришло время приступить к фактическому обзору. Мы обсудили, в каком порядке работать с ними, решив начать с тех, которые охватывают новую функцию. Это было сделано для того, чтобы

  1. сначала убери с дороги большие вещи
  2. ознакомьтесь с требованиями к изменениям API, прежде чем просматривать их

На данный момент я больше ничего не мог сделать, поэтому позволил своему рецензенту приступить к работе. И работу он выполнил! В течение следующих часов я наблюдал, как уведомления Crucible заполняют мой почтовый ящик. Я обдумал его комментарии, подготовил некоторые изменения и сделал несколько заметок.

Обычно я бы ответил в Тигле, и мы бы вступили в письменный разговор. Я вижу в этом большую ценность, особенно в асинхронности и в том, что такие дискуссии продолжаются. Но мы согласились, что в этом случае это сильно затянет процесс, что приведет к большому количеству переходов между многими, многими изменениями.

Вместо этого мы решили закончить обзором некоторых пар. После того, как мой приятель закончил свой первый проход (который занял пару часов), и я увидел все его комментарии, мы сели вместе и просмотрели каждый из них. Это было не только очень весело и познавательно для нас обоих, но и придало нам сил и сосредоточенности после долгого дня обзоров. Мы устранили недоразумения, определили области, требующие дальнейшего изучения, и отметили, какие улучшения я собирался внести. По пути мы документировали каждое принятое нами решение.

Когда тьма осталась позади, это превратилось просто в еще один обзор. В течение следующих нескольких дней я изменял код, как обсуждалось, и он отмечал список улучшений одно за другим. Нужно было уладить пару деталей, но обсуждать было нечего.

Отражение

Ошибаться-это по-человечески, а значит, учиться на своих ошибках. Вот что мы узнали, столкнувшись с потенциально огромным обзором кода:

Признайся!

  • Не просто сваливайте это на своего рецензента, ни чувства, ни отзывы не будут положительными. (Хорошо, мы не узнали об этом сейчас, потому что мы этого не делали. Нам это просто казалось очевидным.)
  • Поговорите со своим рецензентом и обязательно пригласите его или ее на борт.
  • Рассмотрите возможность распределения рабочей нагрузки между несколькими рецензентами, если это возможно.

Создавайте хорошие отзывы!

  • Постарайтесь создать как можно больше разрозненных обзоров, насколько это возможно.
  • Подготовьте каждый обзор, по крайней мере, с одним вводным абзацем, создавая контекст и связывая его с другими обзорами.
  • Определите порядок, который соответствует структуре кода.

Не вытаскивай вещи наружу!

  • Попробуйте взяться за дело, вложив сразу несколько часов.
  • Соберитесь вместе для целенаправленного обсуждения всех замечаний.
  • Найдите время для оперативного внедрения всех изменений.
  • Подумайте о том, чтобы принять несколько менее интенсивный обзор, чтобы ускорить процесс.

((На самом деле, многие из этих предложений применимы к обзорам в целом.)

В целом, я подозреваю, что обзоры были не такими тщательными, как если бы я создавал более мелкие во время работы над этой функцией. Но после того, как этот корабль отплыл, я убежден, что мы сделали все возможное.

Титульное изображение было опубликовано Райаном и Сарой Дидс под CC‑BY‑SA 2.0 .

Оригинал: “https://www.codementor.io/@nicolai518/a-doomed-code-review-1bbg09wcvk”