Качество кода
Как поддерживать
Качество кода
Как поддерживать
Гораздо легче не допускать некачественный код в приложение, чем вычищать его из кодовой базы. Когда некачественный код проникает в репозиторий, быстро появляются участки, которые от него зависят — и чтобы исправить первоначальную проблему, приходится дорабатывать ещё и эти участки.
К примеру, на запуске ГдеМатериала мы предусмотрели очень неудачную архитектуру фильтров в каталоге — использовали PostgreSQL для фасетного поиска. Через несколько месяцев задачи, связанные с фильтрацией товаров, начали занимать неоправданно долго времени — на простейшую доработку админки вместо минут стали уходить дни.
Чтобы пользователи могли фильтровать товары, нам пришлось удалять весь код фильтров и переносить товары в базу, которая умеет работать с неструктурированным данными — Elasticsearch. Это потянуло за собой ещё кучу функциональности, которую пришлось делать заново — подборки товаров, навигацию, маршрутизацию в каталоге.
Эта модель разработки называется Гитхаб Флоу
Чтобы не допускать некачественный код в приложение, выстраивают специальные процессы, которые проверяют новый код на соответствие стандартам качества. Чаще всего проверяют атомарные пакеты изменений — пулреквесты. Один пулреквест — это несколько комитов, объединённых общей целью: к примеру, запустить новую фичу. Когда пулреквест готов, его сливают с основной веткой («мёрджат с мастером») и код попадает на продакшен — пользователи видят новую фичу.
Эта модель разработки называется Гитхаб Флоу
Проверки пулреквестов бывают автоматическими и ручными.
Автоматические проверки в процессе непрерывной интеграции
Метрики, которые можно снять автоматически, нужно отслеживать постоянно. Для этого придумана практика непрерывной интеграции — для каждого комита внутри каждого пулреквеста на сервере запускается процесс «сборки». В сборку включают всё, что нужно для запуска проекта на продакшене — снимают метрики, запускают линтеры, проверяют ненаписанные миграции, проставляют штампы версии для Сентри, компилируют файлы с переводами, пакуют код в докер‑контейнер, выполняют пробные запуски.
Если хотя бы один шаг отработает некорректно, к примеру линтер не пропустит кусок кода, то сборка остановится, а программисту уйдёт сообщение об ошибке.
Непрерывную интеграцию настраивают с помощью Jenkins, или подключают внешние сервисы, к примеру Circle CI или Buddy.works.
Взаимные ручные проверки: код‑ревью
Код‑ревью — это процесс, при котором разработчики проверяют пулреквесты друг‑друга. Выглядит примерно так:
Код‑ревью — это последний барьер, который вручную удерживает плохой код от попадания в приложение. Обычно на код‑ревью проверяют неизмеримые вещи, которые нельзя автоматизировать: соответствие архитектуры принятым правилам, совместимость с планами команды на будущее, понятность кода.
Код‑ревью бывает разрешительным и запретительным. Запретительный код‑ревью — это когда разработчик не может смёрджить пулреквест, пока его не одобрит другой разработчик: к примеру лидер команды или ответственный за область приложения, которую затрагивает пулреквест. Мы в ГдеМатериале используем разрешительную практику — каждый разработчик, прошедший испытательный срок, может смёрджить пулреквест не спрашивая ни у кого одобрения — это повышает ответственность и ускоряет работу.
Инструменты для код‑ревью встроены во все современные системы контроля версий. Для команд с повышенными требованиями есть отдельные инструменты вроде Upsource или Reviewable.
P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.
