Code review и аудит кода: что это и когда заказывать внешнюю проверку
Code review (ревью кода, код-ревью) — это проверка изменений в коде другим разработчиком до того, как они попадут в рабочую версию продукта. Внутри команды это рутина: каждый pull request смотрит коллега. Но у владельца бизнеса вопрос обычно другой: как понять, что подрядчик пишет нормальный код, и можно ли проверить проект, если сам в программировании не разбираешься. Для этого есть внешний аудит кода — разовая независимая экспертиза. Разберём, чем они отличаются, когда какой нужен, что проверяют, сколько стоит и что вы должны получить на выходе.
Что такое code review простыми словами
Разработчик сделал задачу — например, добавил оплату через ЮKassa. Прежде чем изменения попадут на боевой сайт, другой программист (ревьюер) читает код, задаёт вопросы и либо одобряет его, либо возвращает на доработку. Это аналог «второй подписи» в бухгалтерии: один делает, другой проверяет.
Ревью решает сразу несколько задач:
- ловит ошибки до продакшена — исправить баг на этапе ревью в разы дешевле, чем после жалоб клиентов;
- держит единый стиль — код читается так, будто его писал один человек, и новичок входит в проект быстрее;
- распределяет знания — как минимум два человека понимают каждый участок системы, и уход одного разработчика не парализует проект;
- отсекает опасные решения — пароли в коде, SQL-запросы без экранирования, «временные» костыли.
Чем внутреннее код-ревью отличается от внешнего аудита кода
Путаница между этими понятиями — главная причина, по которой владельцы заказывают не то. Если у подрядчика «есть ревью», это не значит, что проект кто-то проверял целиком и независимо.
| Параметр | Code review в команде | Внешний аудит кода |
|---|---|---|
| Кто проводит | Коллега автора из той же команды | Независимый специалист или студия |
| Что смотрят | Конкретное изменение: десятки–сотни строк | Весь проект: архитектура, зависимости, сервер, процессы |
| Когда | Постоянно, на каждую задачу | Разово: приёмка, смена подрядчика, покупка, инцидент |
| Независимость | Низкая: команда проверяет сама себя | Высокая: аудитор не отвечает за написанный код |
| Результат | Комментарии в pull request, одобрение | Отчёт с приоритетами рисков и оценкой исправлений в часах |
| Для кого | Для разработчиков | Для владельца, ЛПР, инвестора |
Хорошая команда делает и то, и другое: ревью — всегда, внешний аудит — в ключевые моменты жизни проекта.
Зачем владельцу бизнеса аудит кода: 5 типовых ситуаций
Контроль подрядчика в процессе работы
Вы платите за разработку месяцами, а видите только интерфейс. Интерфейс может выглядеть отлично, а под капотом — копипаста, отсутствие тестов и обходы ограничений CMS, которые сломаются при первом обновлении. Выборочный аудит раз в 6–12 месяцев показывает, во что на самом деле уходят деньги.
Приёмка проекта
Акт подписан — претензии к качеству кода предъявить почти невозможно. Аудит перед финальной приёмкой фиксирует критичные дефекты, пока подрядчик ещё обязан их исправить по договору.
Передача проекта другой команде
Прежний разработчик ушёл, новый говорит «тут всё надо переписывать». Аудит даёт независимый ответ: действительно ли код не спасти или хватит точечной доработки. Заодно проверяется, всё ли вам передали: репозиторий, доступы, конфигурации сервера. Подробнее о том, как проверить, кому принадлежит проект, — в статье о правах на сайт, домен и код.
Due diligence перед покупкой бизнеса или инвестицией
Покупая интернет-магазин или сервис, вы покупаете и его код. Если платформа держится на устаревшей версии PHP и форке CMS без обновлений, в цену сделки нужно заложить переделку. Аудит превращает «технические риски» в сумму, которую можно обсуждать на переговорах.
Проблемы, у которых нет понятной причины
Сайт тормозит, каждая доработка ломает что-то рядом, сроки задач растут. Это симптомы технического долга, и аудит показывает, где именно он сидит и что из него стоит гасить в первую очередь.
Что проверяют при аудите кода
Объём зависит от задачи, но полноценный технический аудит обычно охватывает семь направлений.
| Направление | Что смотрят | Чем грозит проблема бизнесу |
|---|---|---|
| Архитектура | Структура модулей, связность, разделение логики и отображения | Каждая новая функция дороже предыдущей |
| Безопасность | Инъекции, XSS, авторизация, хранение паролей и ключей, права доступа | Утечка данных, взлом, штрафы за утечку персональных данных (ст. 13.11 КоАП) |
| Зависимости | Версии языка, фреймворка, CMS, библиотек; известные уязвимости | Невозможность обновиться, дыры в безопасности |
| Качество кода | Дублирование, читаемость, соблюдение стандартов, «мёртвый» код | Долгий вход новых разработчиков, регрессии |
| Производительность | Запросы к базе, кэширование, тяжёлые операции, нагрузка | Медленный сайт, потеря конверсии и позиций |
| Тесты и деплой | Покрытие тестами, CI/CD, процесс выкладки, бэкапы | Падения при каждом релизе |
| Документация | README, описание развёртывания, API, схемы | Зависимость от одного разработчика |
Если приоритет — именно защищённость, логичнее заказать отдельный аудит безопасности сайта: там глубже проверяют конфигурацию сервера, доступы и уязвимости, а качество кода остаётся за скобками.
Как устроено code review внутри команды
Владельцу не нужно знать детали, но полезно понимать, как выглядит нормальный процесс, чтобы задать подрядчику правильные вопросы.
- Задача в отдельной ветке. Разработчик не пишет сразу в основной код, а делает изменения в отдельной ветке Git.
- Pull request (merge request). Готовые изменения оформляются как запрос на слияние в GitHub, GitLab или Bitbucket — с описанием, что и зачем сделано.
- Автоматические проверки. Линтеры проверяют стиль, тесты — работоспособность, статические анализаторы (SAST) — типовые уязвимости. Если что-то красное, до человека код не доходит.
- Ручное ревью. Коллега читает изменения, оставляет комментарии к строкам, при необходимости созванивается с автором.
- Доработка и одобрение. Автор исправляет замечания, ревьюер одобряет, изменения сливаются в основную ветку.
Хороший ревьюер идёт по чек-листу: решает ли код задачу, нет ли очевидных ошибок и дыр, понятен ли он без автора, есть ли тесты, не сломает ли изменение соседние модули. Рекомендуемый размер изменения — до нескольких сотен строк: большие pull request проверяют поверхностно.
Как заказать внешний аудит кода: пошагово
- Сформулируйте цель. «Проверить всё» — самый дорогой и размытый запрос. Лучше: «принять проект у подрядчика», «оценить, стоит ли переписывать», «найти причину тормозов каталога».
- Соберите доступы. Репозиторий (read-only достаточно), описание окружения, при необходимости — копия базы без персональных данных и доступ к тестовому серверу.
- Получите оценку объёма. Аудитор смотрит кодовую базу и называет количество часов и сроки. Для типового проекта это 5–15 рабочих дней.
- Зафиксируйте формат результата. Заранее договоритесь, что будет в отчёте и будет ли устная защита выводов.
- Проведите разбор отчёта. Лучше с участием текущего разработчика — чтобы он мог возразить по существу, а не узнавать о претензиях из письма.
Что вы должны получить на выходе
Список из 300 замечаний линтера — это не аудит. Результат должен быть понятен владельцу и пригоден для управленческих решений.
- Резюме для руководителя на 1–2 страницы: общее состояние проекта, главные риски, рекомендация (развивать, рефакторить, переписывать).
- Реестр проблем с приоритетами: критичные (устранить сейчас), высокие (в ближайший месяц), средние и косметика.
- Оценка исправлений в часах по каждой группе проблем — это переводит технические выводы в деньги.
- Конкретика с привязкой к коду: файлы, строки, примеры — чтобы любой разработчик мог проверить вывод.
- План действий: в каком порядке закрывать проблемы и что можно отложить.
Если в отчёте видно, что система в запущенном состоянии, следующим шагом обычно становится рефакторинг кода — поэтапный, а не «переписать всё с нуля».
Сколько стоит аудит кода
Рынок считает аудит двумя способами: фиксированной ценой за пакет или по часам. Ставки у студий и частных специалистов заметно различаются, поэтому сравнивайте не только сумму, но и объём часов и состав отчёта. Ниже — ориентиры при ставке 2 500 ₽/час (так считаем мы). Итоговая сумма зависит от объёма кода, стека, количества интеграций и глубины проверки.
| Проект и формат проверки | Типичный объём работ | Ориентир по цене |
|---|---|---|
| Небольшой сайт на CMS — экспресс-аудит | от 12 часов, 3–5 рабочих дней | от 30 000 ₽ |
| Интернет-магазин или сайт с интеграциями (1С, оплата, доставка) — полный аудит | от 24 часов, 7–10 рабочих дней | от 60 000 ₽ |
| Веб-сервис, личный кабинет, CRM на фреймворке | 40–100 часов | от 100 000 ₽ |
| Due diligence перед покупкой бизнеса или крупной передачей проекта | от 48 часов | от 120 000 ₽ |
| Крупная платформа или мобильное приложение | от 100 часов | от 250 000 ₽ |
Цифры ориентировочные: точную оценку дают после просмотра репозитория. Сроки — от 3–5 рабочих дней для небольшого сайта до 2–4 недель для сложных систем. Как проходит технический аудит сайта и кода в нашей студии, описано на странице услуги.
Как не превратить ревью в войну с подрядчиком
Внешний аудит легко воспринимается командой как обвинение. Если так случилось, вы получите оборону вместо исправлений. Несколько правил, которые снимают конфликт:
- Предупредите заранее. Аудит, о котором подрядчик узнал постфактум, выглядит как подготовка к суду.
- Оценивайте код, а не людей. Формулировки «в модуле заказов нет обработки ошибок оплаты», а не «разработчик некомпетентен».
- Дайте право ответа. Часть решений могла быть осознанным компромиссом по срокам или бюджету — это нормально, если он зафиксирован.
- Разделяйте критичное и вкусовое. Спор о стиле отступов не стоит отношений; уязвимость в авторизации — стоит.
- Закрепите процесс в договоре. Право заказчика на независимый аудит, стандарты кода и срок исправления критичных замечаний лучше прописать до старта.
Типичные ошибки заказчиков
- Аудит после подписания акта. Юридических рычагов уже нет, остаётся только платить за исправления.
- Аудитор с интересом «переписать всё». Студия, которая хочет забрать проект, может сгустить краски. Просите конкретные примеры и оценку в часах, а не общие выводы.
- Автоматический отчёт вместо экспертизы. Прогнать код через анализатор — полчаса. Ценность аудита в ручном разборе архитектуры и отсечении ложных срабатываний.
- Нет цели. Без цели аудит превращается в перечень всех несовершенств без приоритетов, и непонятно, что с ним делать.
- Отчёт положили в папку. Если по результатам не составлен план исправлений с бюджетом, деньги потрачены зря.
Чек-лист владельца: контроль качества кода
- Код лежит в репозитории на вашем аккаунте, а не у подрядчика
- У подрядчика есть процесс code review — вы видели примеры merge request
- Настроены автоматические проверки: линтеры, тесты, статический анализ
- Право на независимый аудит и сроки исправления замечаний прописаны в договоре
- Перед финальной приёмкой запланирован внешний аудит
- Аудитор не связан с командой, которая писала код
- Цель аудита сформулирована одной фразой
- В отчёте есть резюме, приоритеты рисков и оценка исправлений в часах
- Выводы разобраны вместе с текущим разработчиком
- По итогам составлен план исправлений с бюджетом и сроками
Code review — ежедневная практика команды, и её наличие стоит проверить у любого подрядчика. Аудит кода — инструмент владельца: он нужен в моменты, когда цена ошибки максимальна, — при приёмке, смене команды, покупке проекта или при необъяснимом росте сроков и затрат. Хороший аудит отвечает не на вопрос «идеален ли код», а на вопрос «что с ним делать бизнесу и сколько это стоит».