Код ревью может быть как прекрасным инструментом, так и дикой болью в заднице. Всё зависит от того, под каким соусом вы его приготовите.
Конечно же, код ревью должно быть обязательным. Все разработчики должны смотреть и анализировать чужой код. Однако уровень код ревью у всех разный, поэтому качество тоже может скакать. В одном и том же PR один человек увидит странные переменные, а другой - архитектурные косяки.
Этого не избежать никак. Качество код ревью растёт только с опытом и осознанной практикой ревьюера. Но есть несколько простых вещей, которые могут ощутимо улучшить ревью в команде.
Правило #1. Каждый PR должен получить минимум 2 аппрува.
Исключение составляют только команды из 1-2 человек по понятным причинам :)
Это правило позволяет иметь как минимум два разносторонних мнения о написанном коде. Так можно и поделиться опытом, и улучшить качество кода, и избежать некоторых когнитивных искажений и предвзятого отношения. Плюс каждый разработчик будет помнить, что его код будут смотреть.
Правило #2. У каждого PR должно быть хорошее описание. Из описания ревьюер должен понимать, что будет делать код.
Этого правила нужно придерживаться, даже если в описании есть ссылка на тикет в JIRA. Из хорошего описания ревьюер быстрее поймёт, что должен делать код и зачем он вообще написан. Без описания ревьюерам зачастую приходится либо догадываться, либо разбираться с бизнес-требованиями, что усложняет ревью.
Описание одновременно уменьшает затраты времени на код ревью и помогает коллегам сфокусироваться на решении и коде, а не на требованиях к задаче.
Правило #3. PR должен быть в достаточно мере покрыт unit-тестами.
Юниты позволяют убить сразу двух зайцев.
Во-первых, сами по себе юнит-тесты заставляют разработчика писать код так, чтобы его было легко протестировать. Такой код и читать гораздо проще.
Во-вторых, хорошо написанные юнит-тесты помогают понять логику работы компонента/класса/функции/etc. Это ощутимо упрощает ревью, потому что по юнит-тестам зачастую можно легко понять, что сам юнит спроектирован неправильно, перегружен или ещё что-то.
Ещё один момент - у ревьюера появляется возможность подумать, какие бы тесты он сам написал для этого юнита.
Правило #4. Если PR содержит фикс бага, то в нём должен быть соответствующий юнит-тест.
Этот тест должен падать, если багфикс например откатят. Такой тест позволит вам защититься от повторения этого бага в будущем. Если кто-то изменит ваш код в рамках своей задачи, то юнит-тест защитит продукт от регрессии.
Как видите, правила достаточно просты. Однако они требуют дисциплины и привычки. Не рекомендую внедрять их скопом. Возьмите одно любое правило и начните с него.
Если у вас на проекте нет юнит-тестов - самое время начать их писать :)
Stay tuned 🤘