Качество кода: что оно значит для бизнеса и как его обеспечить
Для заказчика качество кода — не вопрос вкуса программиста. Это деньги: сколько стоит добавить функцию, как быстро найти и исправить ошибку, можно ли передать проект другому инженеру. Плохой код работает ровно до первого изменения, а потом каждая правка становится дороже предыдущей. Рассказываю, как я обеспечиваю качество и что вы за это получаете. Общий процесс описан в статье Разработка ПО с нуля под ключ: от идеи до релиза.
Что такое качественный код
Это код, который:
- Правильно работает и это подтверждено проверками.
- Читается другим человеком без помощи автора.
- Легко меняется: правка в одном месте не ломает пять других.
- Безопасен: учитывает Безопасная разработка ПО: как защита закладывается с первого дня.
- Предсказуемо работает под нагрузкой и в нештатных ситуациях.
Почему это влияет на стоимость владения
Первая версия системы обычно стоит меньше, чем следующие десять лет её жизни. Если код запутан, расходы растут:
| Симптом | Последствие для бизнеса |
|---|---|
| Никто не понимает, как это работает | Любая правка идёт с риском и стоит дороже |
| Нет тестов | Каждый релиз — лотерея, ошибки находят пользователи |
| Всё связано со всем | Новая функция требует переделки старых |
| Знания в голове одного человека | Зависимость от конкретного исполнителя |
| Накопился технический долг | Скорость разработки падает со временем |
Моя задача — чтобы график стоимости изменений оставался ровным, а не взлетал со временем.
Практики, которые я применяю
Архитектура и границы модулей
Качество начинается с Архитектура ПО: проектирование и планирование до первой строки кода. Если система разбита на модули с ясными границами и ответственностью, код проще понять и поменять. Внешние зависимости прячу за интерфейсами.
Строгая типизация
Я выбираю языки и настройки, которые ловят ошибки до запуска. В Rust, Java и TypeScript компилятор отсекает целые классы проблем. Например, библиотека sqlx в Rust умеет сверять SQL-запросы со схемой базы при сборке. Чем больше ошибок найдено компилятором, тем меньше их остаётся для продакшна.
Единый стиль и автоматические проверки
Стиль не обсуждается на ревью — его применяют инструменты: форматтеры (например, Prettier, rustfmt) и линтеры (clippy, ESLint). Это экономит время и убирает споры. Код-стайл я ввожу с начала проекта, как это делал на FlameApp.
Код-ревью
Каждое изменение просматривается до слияния. На ревью смотрю не только «работает ли», но и:
- понятны ли имена и структура;
- нет ли дублирования и скрытых связей;
- учтены ли ошибки и граничные случаи;
- не появилась ли уязвимость, об этом подробнее в статье про Безопасная разработка ПО: как защита закладывается с первого дня.
Когда работаю с командой, ревью — часть обучения новичков. Как я выстраивал этот процесс как тимлид, описано в проектах Tezish и FlameApp.
Автоматические тесты
Тесты — страховка от поломок при развитии системы. Я пишу тесты разных уровней: модульные для логики, интеграционные для связки с базой и внешними сервисами, сквозные для ключевых сценариев. Подробности — в статье Тестирование и приёмка ПО: как убедиться, что система работает до релиза.
Непрерывная интеграция
Каждое изменение автоматически собирается, проверяется линтерами и прогоняется через тесты. Если проверка не прошла, изменение не попадёт в основную ветку. Конвейер на GitHub Actions я настраивал, в частности, на проекте FlameApp.
Документация и записанные решения
Код отвечает на вопрос «как», а документация — «зачем». Ключевые архитектурные решения записываются в короткие ADR, а для каждого модуля есть описание назначения. Документация небольшая, но актуальная.
Контроль технического долга
Технический долг неизбежен, но им нужно управлять. Осознанные компромиссы я записываю: что упростили, почему и когда вернуться. Это отличает долг от небрежности. Часть времени в плане отводится на рефакторинг, чтобы система не старела быстрее, чем развивается.
Как измерять качество
Субъективных «мне нравится» недостаточно. Я смотрю на:
- долю кода, покрытого тестами по критичным частям;
- время сборки и прогона проверок;
- количество замечаний на ревью и повторяющиеся проблемы;
- число дефектов, дошедших до пользователей;
- время, нужное новому человеку, чтобы разобраться в проекте и внести первое изменение.
Что получает заказчик
- Исходный код, который можно передать другому инженеру или команде.
- Автоматические проверки, работающие в вашей инфраструктуре.
- Документацию и записанные архитектурные решения.
- Предсказуемую стоимость дальнейших изменений.
Нужен аудит или код, которым не стыдно владеть?
Если у вас есть существующая система, я могу провести аудит кода: найти проблемные места, оценить технический долг и предложить план улучшения. Если вы только начинаете, заложим качество с нуля. Напишите мне: Telegram @w1shmaster.