В попытках сократить ваш time-to-market вы, вполне вероятно, обратите внимание на стадию code review. Действительно, задачи могут “сидеть” в code review очень долго, плюс, разработчики могут выделять на этот этап уйму времени.
Основные причины этого:
🚨Отсутствие дисциплины проведения ревью кода
🤯В рамках ревью делается лишнее
❗Нет четких правил, что именно стоит проверять.
Данная практика настолько важна и настолько часто в ней встречаются проблемы, что в своей книге я решил посвятить отдельную секцию практике code review.
Как повысить эффективность проведения code review? 🤔
Ниже делюсь несколькими советами:
Дополнительно стоит отметить несколько моментов:
✔️Считайте количество возвратов из ревью в разработку: каждый возврат - это время, которое можно сократить
✔️Старайтесь автоматизировать все проверки
✔️Рассмотрите вариант внедрения дизайн ревью: разработчик перед, собственно, кодингом представляет техническое решение “на бумаге”, которое обсуждается командой. Это эффективнее, т.к. корректировки в решение вносятся еще до того, как будет написан код
✔️Обратите внимание на то, чтобы в рамках ревью не выполнялись лишние действия. Например, тестирование, написание тестов, еще что-нибудь.
Всем быстрого и эффективного код ревью!
Основные причины этого:
🚨Отсутствие дисциплины проведения ревью кода
🤯В рамках ревью делается лишнее
❗Нет четких правил, что именно стоит проверять.
Данная практика настолько важна и настолько часто в ней встречаются проблемы, что в своей книге я решил посвятить отдельную секцию практике code review.
Как повысить эффективность проведения code review? 🤔
Ниже делюсь несколькими советами:
- Не надо проверять code-style: сейчас для этого существуют автоматизированные инструменты
- Стоит заранее договориться о том, что же именно проверяется: это может быть структура кода, архитектурные решения, как пишутся миграции для БД и так далее
- Необходимо выстраивать дисциплину проведения ревью: по различным причинам про ревью могут быть забыть, поэтому стоит либо самим ходить напоминать, либо использовать автоматические напоминалки
- Необходимо понять, что делать в случае конфликта: один из вариантов - эскалация для тимлида, который принимает финальное решение
- Необходимо следить за тем, чтобы ревью не замыкалось на одном человеке - тимлиде или сеньоре. Если происходит блокер на одном сотруднике, то необходимо растить разработчиков и вовлекать их в процесс ревью.
Дополнительно стоит отметить несколько моментов:
✔️Считайте количество возвратов из ревью в разработку: каждый возврат - это время, которое можно сократить
✔️Старайтесь автоматизировать все проверки
✔️Рассмотрите вариант внедрения дизайн ревью: разработчик перед, собственно, кодингом представляет техническое решение “на бумаге”, которое обсуждается командой. Это эффективнее, т.к. корректировки в решение вносятся еще до того, как будет написан код
✔️Обратите внимание на то, чтобы в рамках ревью не выполнялись лишние действия. Например, тестирование, написание тестов, еще что-нибудь.
Всем быстрого и эффективного код ревью!
