Code review простыми словами: кто проверяет код в проекте и как заказчику убедиться, что проверка есть

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

Что такое code review?

Code review — это когда один разработчик пишет изменение, а другой читает его построчно и решает: можно ли влить его в основную версию или нужно переделать. Ревью делают до выкладки, на небольших порциях кода, чтобы ошибка не успела дойти до пользователей.

Похоже на редактуру договора: юрист составил текст, второй юрист читает его до подписания и находит пункт, который можно трактовать двояко. Автору такие места не видны — он знает, что имел в виду. Свежий взгляд видит то, что написано на самом деле.

Что проверяющий смотрит в коде:

• Правильность. Делает ли код то, что описано в задаче, и что будет в нестандартной ситуации: пустое поле, двойной клик по кнопке «Оплатить», товар закончился, пока покупатель оформлял заказ.
• Безопасность. Проверяются ли права: может ли клиент, поменяв цифру в адресе страницы, открыть чужой заказ. Защищены ли формы от вредоносного ввода.
• Понятность. Сможет ли через полгода другой разработчик разобраться, что здесь происходит, без звонка автору.
• Повторы и лишнее. Нет ли уже готовой функции, которую написали второй раз, и нужна ли новая внешняя библиотека ради одной мелочи.
• Секреты. Не попали ли в код пароли от базы, ключи платёжного сервиса или токен бота.

В командах Google, которые опубликовали свои правила ревью в открытом доступе, главную цель формулируют так: следить, чтобы общее состояние кода со временем становилось не хуже, а не добиваться идеала в каждой правке (The Standard of Code Review). Для заказчика это хороший ориентир: ревью — не придирки к запятым, а защита проекта от постепенного превращения в хаос, который дорого дорабатывать.

Чем ревью отличается от тестирования?

Тестирование проверяет поведение: нажали кнопку — заявка пришла. Ревью проверяет устройство: как написан код, который отправляет заявку. Сайт может пройти все тесты и при этом хранить пароль от базы в открытом виде или отдавать чужие данные по прямой ссылке. Поэтому нужны оба вида проверок.

Пример из жизни небольшого магазина. Тестировщик оформил заказ, оплатил тестовой картой, получил письмо — всё работает. А проверяющий в ревью заметил, что страница заказа открывается по номеру без проверки, кто её смотрит: перебирая номера, можно увидеть адреса и телефоны других покупателей. Ни один сценарий «покупатель оформляет заказ» эту дыру не покажет, потому что покупатель так не делает.

Обратная ситуация тоже бывает: код прочитан, одобрен, выглядит аккуратно, но на телефоне кнопка уехала за край экрана. Это найдёт только проверка руками на устройстве. Подробно о видах тестирования и о том, что можно проверить самому, — в статье «Тестирование сайта: какие проверки делает разработчик».

Третий слой — автоматические проверки. Это программы, которые запускаются сами при каждой отправке кода:

• линтер — проверяет код на типичные ошибки и единый стиль, как орфографическая проверка в текстовом редакторе;
• автотесты — прогоняют заранее написанные сценарии и сообщают, если новая правка сломала старую функцию;
• проверка зависимостей — предупреждает, если используемая библиотека устарела или в ней нашли уязвимость;
• поиск секретов — ищет в коде строки, похожие на пароли и ключи.

Автоматика снимает с ревьюера рутину, и человек может думать о логике и безопасности, а не о пробелах. Но она находит только то, на что заранее написано правило. Решить, разумно ли устроена логика скидок, программа не может.

	Ревью кода	Тестирование	Автоматические проверки
Кто проверяет	Другой разработчик читает изменения	Человек или программа нажимает кнопки и проходит сценарии	Программы при каждом изменении кода
На что смотрит	На сам код: логику, безопасность, понятность	На поведение: работает ли форма, оплата, фильтр	На формальные правила и заранее написанные тесты
Когда	До слияния изменений в основную ветку	Перед сдачей и после крупных доработок	Каждый раз, когда разработчик отправляет код
Что ловит	Дыры в проверке прав, пароли в коде, запутанные места, лишние зависимости	Сломанные сценарии, вёрстку на телефоне, неверные расчёты	Опечатки, нарушения стиля, поломки старых функций, покрытых тестами
Чего не ловит	Как поведёт себя сайт у живого пользователя	Плохо устроенный код, который пока работает	Всё, о чём не написали правило или тест

Что ревью находит, а что нет?

Ревью хорошо находит ошибки в логике, пропущенные проверки прав, пароли и ключи в коде, запутанные места и лишние зависимости. Хуже — то, что проявляется только в работе: медленные страницы под нагрузкой, вёрстку на конкретном телефоне, ошибки в данных, которые приходят из 1С или CRM.

Чего не стоит ждать от ревью:

• Гарантии отсутствия ошибок. Проверяющий — человек, он смотрит изменение за ограниченное время. Ревью снижает число ошибок, но не обнуляет его.
• Проверки бизнес-логики, которой нет в задаче. Если в задаче не сказано, что скидки не суммируются, ревьюер одобрит код, где они суммируются. Здесь помогает не ревью, а внятное техзадание — как его составить, разобрано в статье о ТЗ на разработку сайта.
• Оценки дизайна и удобства. Это работа дизайнера и ваша приёмка, а не разработчика, читающего код.
• Проверки огромных порций кода. Когда в одном запросе тысячи изменённых строк, внимательно их не прочитать. Хорошая практика — небольшие изменения, каждое под свою задачу.

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

Как выглядит ревью в репозитории?

Ревью живёт в репозитории в виде запросов на слияние: на GitHub они называются pull request, на GitLab — merge request. Разработчик делает изменения в отдельной ветке и открывает запрос «примите мои правки». Проверяющий оставляет комментарии к строкам и выносит решение: одобрить или вернуть на доработку.

Порядок обычно такой:

1. Разработчик берёт задачу, например «добавить выбор времени доставки», и делает её в отдельной ветке, не трогая рабочую версию.
2. Открывает запрос на слияние с описанием: что сделано, как проверить, ссылка на задачу.
3. Автоматически запускаются линтер и тесты. Результат виден прямо в запросе зелёными или красными отметками.
4. Проверяющий читает изменения и пишет замечания к конкретным строкам: «здесь не проверяется, что время доставки в будущем», «этот ключ должен быть в настройках сервера, а не в коде».
5. Автор исправляет, отвечает на комментарии, проверяющий смотрит снова.
6. Когда всё в порядке, проверяющий ставит одобрение, и изменения сливаются в основную ветку, откуда потом выкладываются на сервер.

На GitHub у проверяющего три варианта итогового решения: просто комментарий, одобрение (Approve) или запрос изменений (Request changes) — так это описано в справке GitHub о ревью. Основную ветку можно защитить правилом: слияние только после заданного числа одобрений, а запрос изменений блокирует слияние, пока замечание не снято (справка GitHub о защищённых ветках).

В GitLab есть нюанс тарифов. По документации GitLab, на бесплатном тарифе одобрения необязательные: их можно ставить, но слить изменения можно и без них. Обязательные правила одобрения — на платных тарифах Premium и Ultimate. Значит, на бесплатном GitLab наличие ревью держится на дисциплине команды, и смотреть нужно на сами комментарии, а не на настройки.

Что открыть	Что должно быть	Тревожный признак
Список запросов на слияние (Pull requests или Merge requests)	Изменения приходят порциями, у каждой — название и короткое описание	Запросов нет: всё сразу записывается в основную ветку
Любой закрытый запрос	Комментарии к строкам кода, ответы автора, статус «одобрено»	Запрос открыт и слит одним человеком за минуту без единого комментария
Автор и проверяющий	Разные люди	Автор сам себе одобряет изменения
Значки проверок у запроса	Зелёные отметки: тесты и линтер прошли	Проверок нет совсем или красные отметки, а изменения всё равно слиты
Настройки основной ветки	Слияние только через запрос, нужно одобрение	Прямая запись в основную ветку открыта всем

Как понять, что ваш код проверяют?

Откройте в репозитории список закрытых запросов на слияние и посмотрите три-четыре последних. Если в них есть комментарии другого человека, отметка об одобрении и зелёные значки автоматических проверок — ревью идёт. Если запросов нет, а изменения пишутся прямо в основную ветку, — проверки, скорее всего, нет.

Как пользоваться таблицей выше. Вкладка с запросами на GitHub называется Pull requests, на GitLab — Merge requests. Переключитесь на закрытые запросы, откройте любой и пролистайте ленту: там видно, кто открыл запрос, кто комментировал и кто одобрил. Доступ к репозиторию для этого нужен на чтение; как его получить и что ещё там посмотреть, рассказано в статье о репозитории кода для заказчика.

Несколько тонкостей, чтобы не сделать неверных выводов:

• Мало комментариев — не всегда плохо. Небольшое понятное изменение могут одобрить без замечаний. Тревожно, когда так выглядят все запросы подряд, включая крупные.
• Ревью может идти голосом. Некоторые команды разбирают код на созвоне. Это допустимо, но следов не остаётся, и проверить вы ничего не сможете. Спросите, где фиксируются итоги.
• Один разработчик на проекте. Тогда проверяющего со стороны нет по определению. Спросите прямо, кто смотрит код, кроме автора. Честный ответ «никто, но работают линтер и тесты» полезнее уклончивого: с ним понятно, где нужна внешняя проверка.
• Красные значки и слияние. Если автоматическая проверка провалилась, а изменения всё равно слиты, спросите почему. Иногда причина уважительная, но объяснение должно быть.

Вопросы подрядчику до старта, которые экономят время потом:

• Кто, кроме автора, читает код перед выкладкой?
• Изменения идут через запросы на слияние или сразу в основную ветку?
• Какие автоматические проверки запускаются при каждом изменении?
• Защищена ли основная ветка от прямой записи?
• Дадите ли доступ на чтение к репозиторию на время работ?

Когда нужна независимая проверка кода?

Независимая проверка — это когда код читает разработчик, не связанный с исполнителем. Она нужна в четырёх ситуациях: перед приёмкой крупного проекта, если сомневаетесь в качестве; перед сменой подрядчика; перед сделкой с инвестором или покупателем; когда проект работает с деньгами и персональными данными.

Подробнее о каждой:

• Перед приёмкой. Пока акт не подписан, у вас есть время на проверку. По нашему типовому договору на приёмку отводится 5 рабочих дней. Независимый взгляд за эти дни не прочитает весь проект, но проверит главное: собирается ли он по инструкции, нет ли секретов в коде, как устроены права доступа.
• Перед сменой подрядчика. Новый исполнитель всё равно начнёт с разбора чужого проекта. Как устроен такой аудит и как читать его отчёт, мы разбирали в статье о смене разработчика.
• Перед сделкой. Инвестор или покупатель бизнеса может попросить показать код своему специалисту. Это нормальная практика проверки.
• Деньги и данные. Оплата, личные кабинеты, база клиентов — здесь цена пропущенной ошибки выше цены проверки.

Можно ли вообще показывать код третьим лицам, зависит от договора. В типовом договоре Roboweb.team это прописано прямо (п. 5.4): заказчик вправе давать доступ подрядчикам для обслуживания и доработки, а также знакомить с кодом своих консультантов, аудиторов, инвесторов и потенциальных покупателей бизнеса при условии конфиденциальности. В чужом договоре поищите раздел о конфиденциальности: иногда он запрещает передавать код кому-либо без согласия исполнителя.

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

Когда ревью вам не нужно и какие ошибки бывают?

Строгий процесс ревью с обязательными одобрениями не нужен лендингу или простому сайту на конструкторе, где почти нет своего кода, и прототипу, который сделали на неделю проверить спрос. Там хватает автоматических проверок и ручного тестирования ключевых сценариев.

Частые ошибки заказчиков:

• Требовать ревью, не дав доступа к репозиторию. Без доступа вы получаете только слова «мы всё проверяем».
• Считать, что ревью заменит приёмку. Проверяющий одобрил код, но кнопка на вашем телефоне всё равно может не работать. Главные сценарии проходите сами.
• Заказывать независимую проверку без задачи. Результат будет общим и бесполезным для решений.
• Пугаться числа замечаний. Длинный список, где большая часть — стиль и мелочи, не означает плохой проект. Смотрите на критичные пункты.
• Привести на проверку знакомого, который делает всё на другой технологии. Разработчик на одной платформе часто советует переписать проект на свою. Ищите проверяющего с опытом в вашем стеке.

И ошибки на стороне разработки, которые заметны по репозиторию: огромные запросы на слияние, которые физически нельзя прочитать; автор, одобряющий сам себя; ревью, которое формально проходит за минуту на каждом запросе.

Сколько стоит и как это устроено у нас?

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

По нашему типовому договору исходный код размещается в репозитории заказчика, указанном в приложении к договору, а если репозитория нет — передаётся архивом, в объёме, достаточном для сборки, развёртывания и доработки (п. 5.5). Если код у вас в репозитории, следы проверок из этой статьи вы можете посмотреть сами. Исключительное право на код остаётся у студии, а у вас после полной оплаты — лицензия на весь срок действия права: размещать проект на любом сервере и дорабатывать с любыми подрядчиками. Гарантия — 30 календарных дней с даты акта, она не распространяется на изменения, внесённые заказчиком или третьими лицами.

Ориентиры по прайсу, все цены — «от»:

• корпоративный сайт — от 56 000 ₽, 3–4 дня;
• интернет-магазин — от 104 000 ₽, от 5 дней;
• веб-приложение или SaaS с кабинетами и ролями — от 160 000 ₽, от 10 дней;
• поддержка и развитие уже работающего проекта — от 7 900 ₽ в месяц.

Оплата — 50 % предоплаты и 50 % по акту. Если хотите заказать проект или проверить код текущего, опишите задачу на странице заказной разработки: цену и срок называем до старта и фиксируем в договоре.

Короткие ответы на частые вопросы

Что такое code review простыми словами?

Это когда изменения в коде перед попаданием в рабочую версию читает другой разработчик и либо одобряет их, либо просит переделать. Так ловят ошибки, уязвимости и запутанные места до того, как они попадут на сайт.

Заменяет ли ревью тестирование?

Нет. Ревью смотрит, как написан код, тестирование — как работает готовый сайт или приложение. Нужны оба вида проверки, и они ловят разные ошибки.

Может ли заказчик сам убедиться, что ревью делают?

Да, без знания программирования. Откройте в репозитории список запросов на слияние: если у изменений есть комментарии другого разработчика, отметка об одобрении и зелёные значки автоматических проверок, ревью идёт.

Нужно ли ревью, если над проектом работает один разработчик?

Полноценного взгляда со стороны в этом случае нет, поэтому опору делают на автоматические проверки и тесты. Для важных частей — оплаты, личных кабинетов, работы с персональными данными — разумно разово заказать независимую проверку.

Сколько стоит независимая проверка кода?

Отдельной строки в прайсе Roboweb.team для этого нет: цена зависит от объёма проекта, поэтому называем её после брифа, когда видим репозиторий. Результат — письменный список находок по степени важности.

Услуги и кейсы по теме: заказная разработка · цены и сроки