5 советов по проведению хорошего обзора кода перевод

Обзор кода является одной из самых ценных инженерных практик.

   1. Обзоры кода улучшают качество кода: одна голово хорошо, а две — лучше.
   2. Обзоры кода — это прекрасный инструмент для изучения разработчиками тех частей приложения, которые они в дальнейшем могут сопровождать.
   3. Обзоры кода помогают узнавать лучшие практики от других разработчиков.
   4. Обзоры кода могут использоваться для проверки понятности и простоты всего приложения в целом.

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

   1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
   2. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью проверки соблюдения стандартов кодирования.

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

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

1. Проводите обзоры кода часто.

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

• Чем больше кода необходимо просмотреть, тем больше вероятность того, что разработчик не согласится на последующий рефакторинг.
• Чем дольше разработчик занимается каким-то участком кода, тем более вероятно, что этот участок становится «персональным». Я бы хотел напомнить, что одна из главных проблем разработчиков — это их эго. Если разработчик написал код, который работает, то несмотря на то, что этот код может быть плохим, программистское эго воспротивится любым предложениям по улучшению кода.
• Чем ближе дата релиза, тем менее приоритетными становятся работы по улучшению кода.

Лично я делаю обзор кода каждый раз после того как закончил писать что-нибудь нетривиальное — как правило, несколько раз в день.

2. Сделайте обзоры быстрыми и неформальными.

Забудьте про списки, просто повернитесь и попросите кого-то из коллег уделить вам 5 минут. Если же у вас есть список, то что-нибудь из этого обязательно произойдет:

   1. В ходе обзора будет просмотрено только то, что указано в вашем списке.
   2. Обзоры кода превратятся в формальность. Люди будут как можно меньше времени просматривать код и притворяться, что им это действительно надо.

Короткие и неформальные обзоры — это по сути диалоги, в которых человек не чувствует, что его рецензируют, скорее ему просто советуют.

3. Проводите обзоры кода с разными людьми.

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

   1. Полезно услышать разные точки зрения.
   2. В дальнейшем ваш код сможет сопровождать большее количество людей.
   3. Повышается командное взаимодействие.

4. Настройтесь на позитивный лад.

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

5. Научитесь получать удовольствие от проведения обзоров.

Это самый важный совет. Если вы работаете в команде, в которой люди любят проводить обзоры, то все будут вовлечены в написание кода, который нравится не только автору, но и всей команде.

__________

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