Все посты

4 простых правила для улучшения код ревью

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

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

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

Правило #1. Каждый PR должен получить минимум 2 аппрува. 

Исключение составляют только команды из 1-2 человек по понятным причинам :) 

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

Правило #2. У каждого PR должно быть хорошее описание. Из описания ревьюер должен понимать, что будет делать код. 

Этого правила нужно придерживаться, даже если в описании есть ссылка на тикет в JIRA. Из хорошего описания ревьюер быстрее поймёт, что должен делать код и зачем он вообще написан. Без описания ревьюерам зачастую приходится либо догадываться, либо разбираться с бизнес-требованиями, что усложняет ревью.

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

Правило #3. PR должен быть в достаточно мере покрыт unit-тестами.

Юниты позволяют убить сразу двух зайцев.

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

Во-вторых, хорошо написанные юнит-тесты помогают понять логику работы компонента/класса/функции/etc. Это ощутимо упрощает ревью, потому что по юнит-тестам зачастую можно легко понять, что сам юнит спроектирован неправильно, перегружен или ещё что-то.

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

Правило #4. Если PR содержит фикс бага, то в нём должен быть соответствующий юнит-тест.

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


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

Если у вас на проекте нет юнит-тестов - самое время начать их писать :)

Stay tuned 🤘