Перейти к основному содержимому

Code-review

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

1. Цель​

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

2. Базовые правила​

  1. Merge request создается в статусе Draft.
  2. До перевода в Ready разработчик выполняет самопроверку.
  3. После назначения проверяющего запрещено вносить скрытые правки без уведомления.
  4. Любая правка по замечанию ревью или QA запускает новый цикл проверки.

3. Обязательная самопроверка разработчика​

Перед переводом MR в Ready разработчик обязан:

  1. Проверить, что сборка и обязательные проверки проходят.
  2. Убедиться, что изменения соответствуют архитектурным и код-стандартам.
  3. Удалить временные решения, отладочный код и лишние комментарии.
  4. Обновить документацию, если меняется поведение функционала.
  5. Приложить краткий список изменений и рисков в описание MR.

4. Процесс ревью​

  1. Разработчик переводит MR в Ready и назначает проверяющего.
  2. Проверяющий выполняет ревью:
    • корректность логики;
    • риски регрессий;
    • влияние на производительность;
    • влияние на интеграции и права доступа.
  3. По замечаниям ревью разработчик вносит правки и повторно уведомляет проверяющего.
  4. До подтверждения проверяющего MR не продвигается дальше.

5. Технический чек-лист проверяющего​

При ревью проверяются не только измененные строки, но и последствия изменения для затронутого контура:

  1. В коде нет временных комментариев, закомментированных блоков старого кода, отладочных сообщений и подписей разработчика.
  2. Обработчики событий формы, объекта и менеджера не содержат бизнес-логику целиком, а передают управление в целевые процедуры и функции.
  3. Вложенность условий и циклов не мешает чтению. Граничные случаи вынесены в ранние проверки с Возврат, если это упрощает код.
  4. Сложные условия вынесены в переменные или отдельные методы с говорящими именами.
  5. Исключения не подавляются пустым блоком Исключение; ошибки либо обрабатываются, либо передаются выше.
  6. Транзакции не содержат внешних вызовов, сетевых операций и длительной обработки.
  7. Запросы сохраняют явные соединения, не выбирают лишние поля и остаются пригодными для открытия в конструкторе запросов, если это возможно.
  8. Сообщения пользователю и тексты ошибок объясняют, что произошло и какое действие требуется.
  9. Экспортные процедуры и функции имеют описание публичного интерфейса.
  10. Изменения не обходят существующие механизмы прав, RLS, блокировок и дат запрета.

6. Правила работы после замечаний​

  1. Любой fix должен быть явно отмечен в обсуждении MR.
  2. После fix выполняется повторная самопроверка затронутого контура.
  3. Если правка затрагивает тестовые сценарии, обязательна синхронизация с QA.
  4. При накоплении существенных правок допускается повторный полный раунд ревью.

7. Правила передачи в QA​

Перед передачей в QA должны выполняться условия:

  1. Ревью завершено, критичных замечаний нет.
  2. Обязательные технические проверки завершены успешно.
  3. В MR описаны:
    • состав изменений;
    • риски;
    • ожидаемый результат;
    • требования к повторной проверке.

8. Критерии завершения review-этапа​

  1. MR согласован проверяющим.
  2. Все обязательные замечания закрыты.
  3. Нет неразрешенных конфликтов между кодом, тестами и документацией.
  4. Изменения готовы к прохождению выпускного pipeline.