Эффективные ревью кода: 9 советов от исправившегося скептика

в 5:20, , рубрики: codereview, ит-инфраструктура, организация процессов, Программирование, разработка, ревью кода

Я знал теорию. Ревью кода помогает:

  • Находить баги
  • Обеспечивать читаемость и поддерживаемость кода
  • Распространять знания кода на всю команду
  • Позволять новым членам команды быстрее входить в работу
  • Показывать всем новые подходы к решению задач

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

Я был недавно выпустившимся новичком, разрабатывающий плагины для софтверной компании в Лондоне.
Спустя некоторые время я должен был предоставить блоки идентичного или похожего кода. Они должны быть просмотрены несчастным парнем («Он в этом лучший» — сказал мой менеджер. Ни одно доброе дело (не остается безнаказанным). Тем не менее, каждое ревью возвращалось с чем-то новым. Это казалось бесполезно придирчивым и случайным процессом.
Хуже того, инспекции кода тянулись днями, если не неделями. Когда я получал код обратно, я едва ли мог вспомнить, как его писал. Это не было виной того парня. Он просил разработчика уровня сеньора, но получил меня. Его тошнило от ошибок, которые делают неопытные разработчики, и ревью кода было способом прогнать это разочарование.
Добавьте к этому время, потерянное на синхронизацию ветвей, переключение между контекстами… Я не был любителем этого, не было их и в остальной команде, как выяснилось.
Перескочив на несколько лет вперед, я нахожу себя согласным с твитом Джеффа Этвуда:

«Коллегиальные ревью кода — это большее, что вы можете сделать для улучшения вашего кода.»

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

9 советов про ревью

Для всех:
  • Просматривайте только самое важное, дайте инструментам сделать все остальное
    Вам не надо спорить о форматирование и кодстайле. Есть множество инструментов, которые последовательно освещают эти вопросы. Важно, чтобы код был корректным, понятным и поддерживаемым. Конечно, стиль и форматирование — часть этого, но вы должны дать инструментам проверить эти вещи.
  • Каждый должен просматривать код
    Некоторые люди в этом лучше других. Более опытный человек вполне может обнаружить больше ошибок, и это важно. Но более важным является поддержка позитивного отношения к проверке кода в целом, и это позволит избежать отношения «Мы против них», или того, что для ревью кода является обременительным для кого-то.
  • Просматривайте весь код
    Нет кода слишком короткого или слишком простого. Если вы просматриваете всё, то ничего не останется пропущенным. Более того, это делает ревью частью процесса, привычкой, а не требованием.
  • Усвойте положительное отношение
    Это важно как для ревьюверов, так и для авторов кода. Ревью кода — это не время чтобы получить все пятерки и влиять своим мастерством кодирования.
    Вам не надо принимать оборонительную позицию. Подходите к ревью с позитивным настроем конструктивной критики, и вы сможете построить доверие к этому процессу.

Для ревьюверов:
  • Ревью кода должно быть частым и короткими сессиями
    Эффективность ваших ревью снижается примерно через час. Так что откладывание ревью, чтобы просмотреть их все в одной громадной сессии не поможет никому. Найдите время в течение дня, совпадающее с вашими перерывами — чтобы не нарушать состояние потока и сформировать привычку. Ваши коллеги будут благодарны вам за это. Ожидание может быть неприятно, и они могут решить вопросы быстрее, пока код еще свеж в их головах.
  • Сказать «все хорошо» — это нормально
    Не будьте придирчивы, вам не нужно искать проблему в каждом ревью.
  • Используйте чеклист
    Чеклисты для ревью кода обеспечивают согласованность — они дают убедиться, что каждый просматривает важные и распространенные ошибки.

Для авторов кода:

  • Код должен быть кратким
    Через 200 строк кода эффективность кода снижается значительно. К тому времени, когда вы просмотрите 400 строк, они становятся почти бессмысленными.
  • Обеспечьте контекст
    Давайте ссылки на любые связанные тикеты или спецификации. Есть инструменты для ревью кода типа Kiln, которые помогут с этим. авайте короткие, но полезные сообщения к коммитам и много комментариев в коде. Это может ревьюверу и вы получите меньше вопросов.

Регистрируйтесь сейчас на вебинар «Ревью кода с Kiln»

Присоединяйтесь к нашему следующему онлайн-вебинару. Он поможет новичкам узнать основы об инспекциях кода в нашем продукте.
Мы обсудим:

  • Что такое ревью кода
  • Зачем использовать ревью кода
  • Когда его использовать
  • Что смотреть во время ревью
  • Создание ревью
  • Комментарии в ревью и ответы к ним
  • Работу с существующими ревью
  • Процесс ревью кода

Чтобы занять место, регистрируйтесь сейчас.

Примечание переводчика

Текст — в значительной степени реклама продукта от FogCreek и их вебинаров. Но текст про ревью кода не привязан ни к продукту, ни к предлагаемым ими workflow. Какой бы инструмент вы не использовали, советы про ревью останутся актуальными. И, возможно, кому-то они будут полезны.
Буду рад замечания по улучшению перевода увидеть в личке, а по тексту — в комментариях к посту.

Автор: vovochkin

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js