0 просмотренных постов скрыто
Зачем нужен code review
Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. Конечно, в дополнение к статическому анализу с помощью настроенного pre-commit и тестам;
— выявить проблемы в архитектуре;
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных.
В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками;
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода;
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде;
— дают приток новых идей для улучшений в процессах, подходах и автоматизации;
— увеличивают децентрализацию знаний и bus factor.
В DevFM пишу о полезном для разработчика: инструментах вроде Raycast, об архитектурных схемах, записываю видео по FastAPI + Docker для начинающих. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике.
Повышаем качество разработки
Показать полностью
1
Code Review - Automate/Defere/Pair
Сегодня принёс вам одну из лучших статей по код ревью
В конце статьи автор упоминает фразу, которая уже давно вертелась у меня на языке, и вот здесь она отлично сформулирована.
💡 “Как это ни парадоксально, наличие постоянно полезных и ценных ревью — это признак того, что вы можете добиться большего на других этапах процесса.”
- Исправлять архитектурные проблемы на фазе код ревью — слишком дорого
- Люди не должны вручную искать проблемы, которые можно найти автоматически
- Одна из целей код ревью — постоянно сужать его рамки, позволяя разработчикам постоянно обнаруживать, что может быть улучшено в других частях процесса разработки
- Документация
- Онбординг
- Линтеры
- Статические анализаторы
- и т.д.
Также ещё одна мысль, которую доносит автор — “код ревью не должно быть одинаковым для всех изменений”.
🐌 Проблемы медленных ревью
- Они медленные 🤷♂️ — замедляют релиз на несколько часов или дней
- Поверхностные — не улучшают качество кода, не происходит обмен знаниями.
- Если ревью происходит медленно — разработчики начинают создавать большие пул реквесты, что увеличивает нагрузку на ревьюера и делает код ревью ещё медленнее.
Подходы, которые описываются в статье
Автор долго придерживался принципа Ship / Show / Ask
- 🚢 Ship. Изменения простые, нет знаний, которыми стоит поделиться — льём в прод без ревью.
- 🔍 Show. Если изменения простые, но в них есть что-то полезное и ими стоит поделиться (например вы написали новую функцию или компонент), то — сливайте изменения, а потом просите о код ревью. Код ревью — не блокирующий. Я обычно называю это постревью.
- ❓Ask. Если вы вносите сложные изменения — дождитесь код ревью и только потом сливайте изменения. Тут код ревью блокирующий.
Со временем он его немного перефразировал в Automate / Defer / Pair
- 🤖 Automate. Если в изменениях нет знаний, которыми стоило бы поделиться, а в коде особо нечего улучшить — пропускаем ревью и полагаемся на линтеры, статические анализаторы и тесты.
- ↪️ Defer (отложить). В зрелом и проверенном процессе разработки большинство изменений нужно ревьюить, но ревью не должно быть блокирующим. Это особенно хорошо работает, когда новая фича деплоится за фича флагом и можно спокойно получить фидбек после деплоя.
- 👯 Pair. Если корректность изменений очень важна: их сложно откатить или изменения связаны с оплатой, или же изменения достаточно сложные — то вам нужно работать в паре с ревьюером, созвониться и объяснить ему изменения, чтобы он был в контексте и смог сделать ревью быстрее и качественнее.
https://t.me/cherkashindev/215
Показать полностью
1
Самая обычная ситуация на code review
Показать полностью
1
А как иначе?
Взято из телеграмма - Инкогнито
Как правильно “придираться” во время код ревью
Когда вы проверяете код своего коллеги не нужно требовать от него “идеального” кода.
ℹ️ Правило такое: вам следует апрувить изменения, если они улучшают в целом кодовую базу, даже если они не идеальны, ведь идеального кода не существует. Код можно сделать лучше чем он был до этого, но не идеальным.
Если вы увидели, какие-то небольшие помарки в коде, которые совершенно не критичны, то не нужно категорично требовать их исправления. Вы можете оставить комментарии, и оставить на усмотрение автора, необходимо ли вносить какие-то изменения.
ℹ️ В стандартах код ревью гугла, описано, что в таких ситуациях можно использовать префикс NIT, в комментариях к пул реквесту. NIT — сокращение от “nitpick” или “придираться”.
❓В каких ситуациях стоит использовать NIT
- Чтобы выразить своё мнение или личное предпочтение. Очень важно отличать такие комментарии, от фактов. Довольно часто ревьюеры выставляют собственное мнение как истину и единственно верное решение
- Чтобы указать автору на мелкие замечания, которые не обязательно исправлять
- В целях обучения, когда вы менторите начинающего разработчика и ваш комментарий носит чисто образовательный характер
Подробнее об этом можно почитать здесь - The Standard of Code Review
Показать полностью
1