К примеру, на запуске ГдеМатериала мы предусмотрели очень неудачную архитектуру фильтров в каталоге — использовали PostgreSQL для фасетного поиска. Через несколько месяцев задачи, связанные с фильтрацией товаров, начали занимать неоправданно долго времени — на простейшую доработку админки вместо минут стали уходить дни.

Чтобы пользователи могли фильтровать товары, нам пришлось удалять весь код фильтров и переносить товары в базу, которая умеет работать с неструктурированным данными — Elasticsearch. Это потянуло за собой ещё кучу функциональности, которую пришлось делать заново — подборки товаров, навигацию, маршрутизацию в каталоге.

Чтобы не допускать некачественный код в приложение, выстраивают специальные процессы, которые проверяют новый код на соответствие стандартам качества. Чаще всего проверяют атомарные пакеты изменений — пулреквесты. Один пулреквест — это несколько комитов, объединённых общей целью: к примеру, запустить новую фичу. Когда пулреквест готов, его сливают с основной веткой («мёрджат с мастером») и код попадает на продакшен — пользователи видят новую фичу.

Метрики, которые можно снять автоматически, нужно отслеживать постоянно. Для этого придумана практика непрерывной интеграции — для каждого комита внутри каждого пулреквеста на сервере запускается процесс «сборки». В сборку включают всё, что нужно для запуска проекта на продакшене — снимают метрики, запускают линтеры, проверяют ненаписанные миграции, проставляют штампы версии для Сентри, компилируют файлы с переводами, пакуют код в докер‑контейнер, выполняют пробные запуски.

Если хотя бы один шаг отработает некорректно, к примеру линтер не пропустит кусок кода, то сборка остановится, а программисту уйдёт сообщение об ошибке.

Код‑ревью — это процесс, при котором разработчики проверяют пулреквесты друг‑друга. Выглядит примерно так:

Код‑ревью — это последний барьер, который вручную удерживает плохой код от попадания в приложение. Обычно на код‑ревью проверяют неизмеримые вещи, которые нельзя автоматизировать: соответствие архитектуры принятым правилам, совместимость с планами команды на будущее, понятность кода.

Код‑ревью бывает разрешительным и запретительным. Запретительный код‑ревью — это когда разработчик не может смёрджить пулреквест, пока его не одобрит другой разработчик: к примеру лидер команды или ответственный за область приложения, которую затрагивает пулреквест. Мы в ГдеМатериале используем разрешительную практику — каждый разработчик, прошедший испытательный срок, может смёрджить пулреквест не спрашивая ни у кого одобрения — это повышает ответственность и ускоряет работу.

Инструменты для код‑ревью встроены во все современные системы контроля версий. Для команд с повышенными требованиями есть отдельные инструменты вроде Upsource или Reviewable.