Руководство по код-ревью

Previous Next

Принципы и чек-лист для code review в AIOps.

Цели ревью

  • Поддержание качества и согласованности кода.
  • Передача знаний и выявление проблем до merge.
  • Соблюдение архитектуры (слои, паттерны, контракты).

Что проверять

Функциональность и дизайн

  • Логика соответствует задаче и требованиям.
  • Нет лишней сложности; повторное использование существующего кода где уместно.
  • Границы слоев соблюдены (core не зависит от infra/api).
  • Ошибки обрабатываются; граничные случаи учтены.

API и контракты

  • Изменения proto/REST обратно совместимы или версионированы.
  • Именование и форматы ответов/ошибок соответствуют API Guidelines.

Безопасность и данные

  • Нет утечки секретов, паролей, PII в логах и ответах.
  • Ввод валидируется; нет неконтролируемого использования пользовательских данных в запросах к БД/внешним сервисам.

Тесты

  • Новый код покрыт тестами (unit и при необходимости integration).
  • Тесты читаемые и стабильные; без нестабильных таймингов где можно избежать.

Стиль и стандарты

  • Соответствие Coding Standards и pre-commit (ruff, mypy).
  • Понятные имена переменных и функций; нет «магических» чисел без констант.

Документация и операции

  • README/документация обновлена при изменении запуска, конфигурации или контрактов.
  • Изменения, влияющие на деплой или миграции, отражены в соответствующей документации.

Как оставлять комментарии

  • Конкретно: что не так и по возможности как исправить.
  • Вежливо и по делу; отделять предложения от обязательных замечаний.
  • Для мелких правок можно предлагать готовый патч или одобрять с пометкой «minor».

Ответственность автора

  • Описание MR: что сделано, зачем, как проверить.
  • Реагировать на комментарии; вносить правки или обсудить в треде.
  • Убедиться, что CI зеленый перед повторным запросом ревью.

Связанные страницы

Стратегия ветвления Критерии готовности