Обзор кода является одной из самых ценных инженерных практик.
1. Обзоры кода улучшают качество кода: одна голово хорошо, а две — лучше.
2. Обзоры кода — это прекрасный инструмент для изучения разработчиками тех частей приложения, которые они в дальнейшем могут сопровождать.
3. Обзоры кода помогают узнавать лучшие практики от других разработчиков.
4. Обзоры кода могут использоваться для проверки понятности и простоты всего приложения в целом.
Как вы могли заметить, в этом списке я не упомянул, что проведение обзоров кода помогает находить ошибки и соблюдать стандарты кодирования, и вот почему:
1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
2. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью проверки соблюдения стандартов кодирования.
10 лет назад эти два пункта имели бы смысл в обзорах кода. Однако сейчас вы должны использовать автоматические средства тестирования и инструменты, следящие за оформлением кода. Это не значит, что во время проведения обзора вы не должны замечать ошибок кодирования и оформления, это значит, что их нахождение не является целью проведения обзора кода.
Исходя из этой точки зрения, позвольте вам дать 5 советов по проведению хорошего обзора кода.
В моей работе были случаи, когда я страдал от того, что обзор кода был проведен слишком поздно. Я работал в компании, где масштабный обзор кода всего приложения был последней стадией разработки. Это было абсолютно бесполезно, поскольку поздние обзоры кода имеют следующие недостатки.
Лично я делаю обзор кода каждый раз после того как закончил писать что-нибудь нетривиальное — как правило, несколько раз в день.
Забудьте про списки, просто повернитесь и попросите кого-то из коллег уделить вам 5 минут. Если же у вас есть список, то что-нибудь из этого обязательно произойдет:
1. В ходе обзора будет просмотрено только то, что указано в вашем списке.
2. Обзоры кода превратятся в формальность. Люди будут как можно меньше времени просматривать код и притворяться, что им это действительно надо.
Короткие и неформальные обзоры — это по сути диалоги, в которых человек не чувствует, что его рецензируют, скорее ему просто советуют.
По возможности, просите разных людей посмотреть ваш код. Есть три главные причины, почему об этом каждый раз нужно просить нового человека.
1. Полезно услышать разные точки зрения.
2. В дальнейшем ваш код сможет сопровождать большее количество людей.
3. Повышается командное взаимодействие.
Памятуя о том, что одна из главных проблем разработчиков — это их эго, позитивный настрой поможет вам сделать обзоры более приятными, а все участники скорее согласятся с предлогаемыми в ходе обзоров изменениями. И помните: вы — это не ваш код!
Это самый важный совет. Если вы работаете в команде, в которой люди любят проводить обзоры, то все будут вовлечены в написание кода, который нравится не только автору, но и всей команде.
__________
1. Обзоры кода улучшают качество кода: одна голово хорошо, а две — лучше.
2. Обзоры кода — это прекрасный инструмент для изучения разработчиками тех частей приложения, которые они в дальнейшем могут сопровождать.
3. Обзоры кода помогают узнавать лучшие практики от других разработчиков.
4. Обзоры кода могут использоваться для проверки понятности и простоты всего приложения в целом.
Как вы могли заметить, в этом списке я не упомянул, что проведение обзоров кода помогает находить ошибки и соблюдать стандарты кодирования, и вот почему:
1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
2. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью проверки соблюдения стандартов кодирования.
10 лет назад эти два пункта имели бы смысл в обзорах кода. Однако сейчас вы должны использовать автоматические средства тестирования и инструменты, следящие за оформлением кода. Это не значит, что во время проведения обзора вы не должны замечать ошибок кодирования и оформления, это значит, что их нахождение не является целью проведения обзора кода.
Исходя из этой точки зрения, позвольте вам дать 5 советов по проведению хорошего обзора кода.
1. Проводите обзоры кода часто.
В моей работе были случаи, когда я страдал от того, что обзор кода был проведен слишком поздно. Я работал в компании, где масштабный обзор кода всего приложения был последней стадией разработки. Это было абсолютно бесполезно, поскольку поздние обзоры кода имеют следующие недостатки.
- Чем больше кода необходимо просмотреть, тем больше вероятность того, что разработчик не согласится на последующий рефакторинг.
- Чем дольше разработчик занимается каким-то участком кода, тем более вероятно, что этот участок становится «персональным». Я бы хотел напомнить, что одна из главных проблем разработчиков — это их эго. Если разработчик написал код, который работает, то несмотря на то, что этот код может быть плохим, программистское эго воспротивится любым предложениям по улучшению кода.
- Чем ближе дата релиза, тем менее приоритетными становятся работы по улучшению кода.
Лично я делаю обзор кода каждый раз после того как закончил писать что-нибудь нетривиальное — как правило, несколько раз в день.
2. Сделайте обзоры быстрыми и неформальными.
Забудьте про списки, просто повернитесь и попросите кого-то из коллег уделить вам 5 минут. Если же у вас есть список, то что-нибудь из этого обязательно произойдет:
1. В ходе обзора будет просмотрено только то, что указано в вашем списке.
2. Обзоры кода превратятся в формальность. Люди будут как можно меньше времени просматривать код и притворяться, что им это действительно надо.
Короткие и неформальные обзоры — это по сути диалоги, в которых человек не чувствует, что его рецензируют, скорее ему просто советуют.
3. Проводите обзоры кода с разными людьми.
По возможности, просите разных людей посмотреть ваш код. Есть три главные причины, почему об этом каждый раз нужно просить нового человека.
1. Полезно услышать разные точки зрения.
2. В дальнейшем ваш код сможет сопровождать большее количество людей.
3. Повышается командное взаимодействие.
4. Настройтесь на позитивный лад.
Памятуя о том, что одна из главных проблем разработчиков — это их эго, позитивный настрой поможет вам сделать обзоры более приятными, а все участники скорее согласятся с предлогаемыми в ходе обзоров изменениями. И помните: вы — это не ваш код!
5. Научитесь получать удовольствие от проведения обзоров.
Это самый важный совет. Если вы работаете в команде, в которой люди любят проводить обзоры, то все будут вовлечены в написание кода, который нравится не только автору, но и всей команде.
__________
В комментариях можно поделиться, проводите ли вы обзоры кода, как у вас это происходит, есть ли какой-нибудь интересный опыт и т.д.