Ниже — компактный набор метрик и практик с указанием, какие правила жёстче, а какие гибче в учебном контексте.
Метрики (измеримые)
- Покрытие тестами: цель командно/проекта — минимум $\ge 70\%$, для контрольных задач — $\ge 80\%$.
- Проходимость CI: процент сборок без ошибок — целевой $\ge 95\%$.
- Линтинг/статический анализ: критические ошибки — $\le 0$, предупреждения — допустимы, но снижают оценку.
- Сложность функций (цикломатическая): рекомендуемая средняя граница на функцию — $\le 10$, допускается до $\le 15$ в учебных заданиях.
- Дублирование кода: процент дубликатов в проекте — стремиться к $\le 5\%$.
- Размер PR: рекомендуемая максимальная величина — $\le 200$ строк изменений; для учебных задач допускается до $\le 400$.
- Время обзора/слияния PR: медиана — $\le 48$ часов.
- Количество замечаний в review (качество обратной связи): минимум $\ge 1$ содержательный комментарий от каждого рецензента для оценочных PR.
Практики (процесс)
- Code reviews: минимум один рецензент + чек-лист (см. ниже). Для итоговых/оценочных работ — два рецензента.
- Чек-лист при review (обязательные пункты): корректность (тесты), читаемость, отсутствие очевидных багов/ресурсных утечек, согласованность с архитектурой задания.
- Pair programming / peer review: регулярные сессии $1\text{–}2$ раза в неделю для новичков.
- CI/CD: автоматический запуск тестов, линтеров и сборки на каждый PR; блокировка слияния при провале критических проверок.
- Статический анализ: использовать форматтер (auto-fix) + линтер + тайпчекер (если язык поддерживает). Форматирование — автоправить в CI.
- Тестирование: требовать модульные тесты для каждой публичной функции и интеграционные тесты для критических сценариев.
- Коммиты и сообщения: один логичный набор изменений = один коммит; правило: сообщение в стиле «тип: что сделано» (напр., «fix: обработка null в X»).
- Документация: краткий README, комментарии для публичных API/функций и пример запуска.
- Ретроспективы ошибок: раз в спринт разбирать частые баги и правила их предотвращения.
Что делать жёстко (обязательное автоматическое соблюдение)
- Проходящие тесты в CI: блокировать слияние при провале.
- Критические линт-ошибки/безопасность: блокировать слияние (SQL-инъекции, XSS в веб-проектах и т.п.).
- Форматирование кода: применять автоформаттер в pre-commit/CI и требовать нулевого отклонения (чтобы снять обсуждения стиля).
- Плагиат/академическая честность: нулевой толерантности — фиксируется и рассматривается отдельно.
Что делать гибче (педагогически)
- Стиль кода/нейминг: обсуждать в review, ставить рекомендации, не всегда блокировать.
- Архитектурные решения: допускать экспериментальные подходы и альтернативные реализации, оценивать обоснованность выбора.
- Небольшие нарушения сложности/дублирования в ранних задачах: штрафовать мягко, объяснять как улучшить.
- Количество тестов: в учебных задачах допустимы частичные покрытия с поэтапным увеличением требований.
Чек-лист для рецензента (короткий)
- Тесты: есть ли тесты и проходят ли они?
- Понятность: читается ли код без лишних усилий?
- Безопасность/ресурсы: нет ли утечек/небезопасных конструкций?
- Производительность: критические узкие места?
- Соответствие заданию: решает ли код поставленную задачу?
- Документация/комментарии: есть ли инструкции по запуску и пояснения для нестандартных мест?
Оценивание/весы (пример, можно адаптировать)
- Корректность (тесты, функциональность): $40\%$
- Code review и качество кода: $25\%$
- Тестовое покрытие и CI: $15\%$
- Документация и читаемость: $10\%$
- Архитектура/дизайн и дополнительные критерии: $10\%$
Рекомендация по внедрению
- Автоматизируйте всё, что можно (форматтеры, линтеры, тесты) — это снимает споры о стиле и концентрирует внимание на архитектуре и логике.
- Разделяйте правила на hard (CI-блоки) и soft (обсуждаемые в review), особенно для новичков.
- Документируйте критерии оценки и отображайте метрики в простом dashboard для студентов.
Если хотите, могу дать готовые конфигурации для популярных стэков (Python/JS/Java) и пример чек-листа в формате файла.