Code review — это очень трудоёмкая ручная работа, требующая квалифицированного исполнителя и человеческого взаимодействия. Поэтому зачастую она ещё и является узким бутылочным горлышком на пути выпуска релиза. Как можно это горлышко расширить и увеличить скорость прохождения задач до заказчика?
Откуда это горлышко появляется? Ключевой фактор риска здесь — человеческий. Нельзя гарантировать, насколько быстро код будет проверен, насколько быстро будет исправлен, что не будет никаких споров при решении замечаний. Проверка кода — сложный мыслительный процесс и требует сосредоточенности, внимания, понимания того, как работает написанный код. 4 пулл-реквеста в день — это, пожалуй, предельный объём, который сможет эффективно рассмотреть и довести до конца проверяющий. И это уже 50% всего рабочего времени. Помимо этого есть ещё свои задачи, самих пулл-реквестов может больше четырёх.
Теоретически предполагается, что с течением времени качество кода будет постепенно расти. На проверку кода, соответственно, будет уходить всё меньше и меньше времени. Особенно, когда разработчику разъяснена ответственность за качество выпускаемого кода и он обязан самостоятельно исправить все замечания. Как вода камень точит, так и узкое горлышко постепенно расширяется.
Значительно облегчить ревью кода помогут автоматизированные инструменты, которые могут быть встроены в pipeline-сценарий DevOps. Во-первых, проверять соответствие программного кода Style Guide могут линтеры. У каждого языка программирования могут быть свои инструменты, например, ESLint для JavaScript, Klint для Kotlin, Stylelint для CSS. Если найдено хотя бы одно замечание, то сборка будет прервана, тем самым сигнализируя разработчика о необходимости её устранения. Пока проблема не будет устранена, сборка проекта будет заблокирована.
Линтер — это самая простейшая проверка кода. Более продвинутой проверкой является анализ кода с помощью статического анализатора. Одним из наиболее известных анализаторов является SonarQube. Ключевой функцией этого инструмента является настройка Quality Gate. Она позволяет выполнять анализ legacy-программного кода, зафиксировав максимально возможные метрики как всего кода, так и нового. Постепенно снижая планку в Quality Gate, можно со временем достичь полного исправления замечаний.
Включение линтера в проект потребует сразу полного исправления замечаний для прохождения сборки. Это может занять значительное время и создать конфликты при мёрджинге кода. SonarQube с функцией Quality Gate позволит распределить эти риски по времени.
В настоящее время есть ещё и архитектурные автотесты, позволяющие проверять заранее установленные архитектурные правила (например, ArchUnit). Прерывать сборку и могут классические Unit- и интеграционные автотесты.
Включение автоматических проверок позволяют обезопасить от включения в ветку master от нежелательного кода. Это позволяет значительно сэкономить время на code review и в большей мере сосредоточить внимание на логику выполненной задачи.
#Code Review #SonarQube #devops #it #ит
