Два инженера, которые смотрят код, ищут пути его улучшения, делятся своим опытом — этот замечательный процесс называется Code review. Именно эту неотъемлемую часть жизни разработчика я хочу разложить по полочкам. В этой статье я опишу как провести Code review, на что обратить внимание, как сделать этот процесс более эффективным.
А начнем мы с главного — обсудим зачем вообще нужно Code review.
Какой профит? 🎯
Code review создано не только для улучшения кода, это социальный процесс, в котором принимают участие коллеги с двумя ролями — автор и ревьювер.
Вы можете делать друг друга лучше, так как каждый делится своим опытом и мнением. Это позволяет быстро обучаться, находить пробелы в знаниях и стремительно их заполнить.
Ловушка
Code review стоит воспринимать исключительно в положительном ключе. Все плюсы могут быть утеряны, если автор воспринимает обсуждение как критику.
Какой процесс проведения Code review?
Перед началом ревью я рекомендую создать документ в котором будут записываться список рекомендаций от ревьювера.
🔄 Code-review — процесс итерационный и на каждой итерации происходит следующее:
- Автор делится кодом
- Ревьювер смотрит код, формирует фидбек и отправляет его автору
- Автор реагирует на фидбек уточняющими комментариями или изменениями в коде и снова отдает код на ревью.
⚽️ Такая игра в пас приведет к чистому коду и шарингу знаний, все в плюсе.
Не забываем есть слона по кусочкам, так как если мы имеем дело с большим куском кода — лучше провести ревью небольшого участка кода, разобраться со всем что нашли и переходить к следующему куску слона кода.
Как писать фидбек?
Фидбек должен быть изложен как рекомендации, а не команды к выполнению.
Рекомендации лучше команд, потому что это дает право последнего слова. И вполне возможно, что если аргументы автора будут сильны — в продакшн пойдет именно его реализация поставленной задачи.
Круто, если ревьювер предоставляет наброски кода, возможно даже proof of concept того как бы он решил поставленную задачу.
Критикуем код, а не кодера.
Цель Code review — сделать код лучше, а не найти виновных. Чтобы повысить командный дух и понизить напряжение — используй слово Мы, вместо Ты. Нужно размыть конкретику о том кто написал код, гораздо важнее сосредоточится на решении проблем, которые были найдены в коде.
Кстати, в коде нужно искать не только проблемы, а и положительные моменты. За элегантные решения, грамотное программирование ревьювер может похвалить автора 👍
One more thing совет ☝️
Настоятельно рекомендую время от времени менять ревьюверов. Это позволит получить новый взгляд и опыт для всех сторон.
На что обращать внимание? 🧐
Руководствуясь рекомендациями от Google по проведению Code Review, можно выделить следующие пункты на которые нужно обратить внимание при Core Review:
- Дизайн: хорошо ли спроектирован и вписывается ли код в вашу систему?
- Функциональность: ведет ли код так, как предполагал автор? Подходит ли эта реализация для выполнения поставленной задачи?
- Сложность: можно ли сделать код проще? Сможет ли другой разработчик легко понять и использовать этот код, когда он встретится с ним в будущем?
- Тесты: покрыт ли новый функционал тестами?
- Именование: выбрал ли разработчик четкие имена для переменных, классов, методов и т. д.?
- Комментарии: комментарии понятны и полезны?
- Стиль: соответствует ли код принятым у вас стайлгайдам?
- Документация: обновил ли разработчик соответствующую документацию (CHANGELOG, как минимум)?
Где срезать углы? 📐
Практики, которые помогут сократить время, затраченное на ревью:
- Устранение ошибок до ревью. Проверяй свой код самостоятельно, велика вероятность, что еще до ревью ты сам найдешь пути для улучшения. Проверив код самостоятельно, ты экономишь время ревьювера, он этого не забудет ☺️
- Создай со своей командой стайлгайд и усовершенствуйте его итеративно. Стайлгайд положит конец спорам во время Code review о нейминге, комментариях и т.д.
- Не запаривайтесь над мелочами, сконцентрируйтесь на интересных вещах. Пусть за форматирование и прочее беспокоится автоматизированный анализатор и форматтер кода, а не ревьювер с автором. Сэкономленное время лучше потратить на тимбилдинг 🍻
- Правильные сообщения в коммитах помогут быстро влиться в контекст. Не забывайте, что сообщение коммита — часть документации для ревью ☝️
Заключение 🔑
Мы с тобой определили, что Code review помогает программисту развиваться. Критика — плохо, а рекомендации — хорошо.
Еще мы выделили перечень моментов на которые стоит обращать внимание во время Code review и определили как можно оптимизировать этот процесс. Этих знаний будет вполне достаточно, чтобы проводить здоровое Code review от которого все будут только в плюсе ➕
Куда дальше? 🛣
Самое время написать стайлгайд для своего проекта или же подумать над интеграцией автоматического анализа и форматирования кода. А возможно кому-то стоит переосмыслить Code review и начать воспринимать его более положительно, что позволит получить наслаждение от каждой сессии Code review 🤘