👉️ Телеграм-канал

Сегодня принёс вам одну из лучших статей по код ревью

https://refactoring.fm/p/thoughts-on-code-reviews

В конце статьи автор упоминает фразу, которая уже давно вертелась у меня на языке, и вот здесь она отлично сформулирована.

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

- Исправлять архитектурные проблемы на фазе код ревью — слишком дорого
- Люди не должны вручную искать проблемы, которые можно найти автоматически
- Одна из целей код ревью — постоянно сужать его рамки, позволяя разработчикам постоянно обнаруживать, что может быть улучшено в других частях процесса разработки
- Документация
- Онбординг
- Линтеры
- Статические анализаторы
- и т.д.

Также ещё одна мысль, которую доносит автор — “код ревью не должно быть одинаковым для всех изменений”.

🐌 Проблемы медленных ревью

- Они медленные 🤷‍♂️  — замедляют релиз на несколько часов или дней
- Поверхностные — не улучшают качество кода, не происходит обмен знаниями.
- Если ревью происходит медленно — разработчики начинают создавать большие пул реквесты, что увеличивает нагрузку на ревьюера и делает код ревью ещё медленнее.

Подходы, которые описываются в статье

Автор долго придерживался принципа Ship / Show / Ask

- 🚢 Ship. Изменения простые, нет знаний, которыми стоит поделиться — льём в прод без ревью.
- 🔍 Show. Если изменения простые, но в них есть что-то полезное и ими стоит поделиться (например вы написали новую функцию или компонент), то — сливайте изменения, а потом просите о код ревью. Код ревью — не блокирующий. Я обычно называю это постревью.
- ❓Ask. Если вы вносите сложные изменения — дождитесь код ревью и только потом сливайте изменения. Тут код ревью блокирующий.

Со временем он его немного перефразировал в Automate / Defer / Pair

- 🤖 Automate. Если в изменениях нет знаний, которыми стоило бы поделиться, а в коде особо нечего улучшить — пропускаем ревью и полагаемся на линтеры, статические анализаторы и тесты.
- ↪️ Defer (отложить). В зрелом и проверенном процессе разработки большинство изменений нужно ревьюить, но ревью не должно быть блокирующим. Это особенно хорошо работает, когда новая фича деплоится за фича флагом и можно спокойно получить фидбек после деплоя.
- 👯 Pair. Если корректность изменений очень важна: их сложно откатить или изменения связаны с оплатой, или же изменения достаточно сложные — то вам нужно работать в паре с ревьюером, созвониться и объяснить ему изменения, чтобы он был в контексте и смог сделать ревью быстрее и качественнее.

https://t.me/cherkashindev/215

Когда вы проверяете код своего коллеги не нужно требовать от него “идеального” кода.

ℹ️ Правило такое: вам следует апрувить изменения, если они улучшают в целом кодовую базу, даже если они не идеальны, ведь идеального кода не существует. Код можно сделать лучше чем он был до этого, но не идеальным.

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

ℹ️ В стандартах код ревью гугла, описано, что в таких ситуациях можно использовать префикс NIT, в комментариях к пул реквесту. NIT — сокращение от “nitpick” или “придираться”.

❓В каких ситуациях стоит использовать NIT

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

Подробнее об этом можно почитать здесь - The Standard of Code Review