Кратко — последовательность шагов и критерии для code review в лабораторной работе, с указанием на что смотреть преподавателю и студенту.
Шаги процесса review
1. Подготовка
- Ознакомиться с заданием и критериями оценки.
- Склонировать/собрать проект и запустить — проверить, что репозиторий воспроизводим: сборка и запуск без ручных правок.
- Преподавателю: проверить соответствие решения формулировке задания и ограничений.
- Студенту: убедиться, что README и инструкции запуска актуальны.
2. Автоматическая проверка
- Запустить сборку, линтер, форматтер, тесты и CI.
- Обратить внимание на ошибки сборки, warning'и, статический анализ.
- Инструменты: linters, formatter (например, ESLint/flake8/clang-format), CI.
3. Функциональное тестирование
- Проверить корректность на типичных и граничных данных, некорректных вводах.
- Преподавателю: сравнить с ожидаемым поведением по ТЗ; проверить обработку ошибок.
- Студенту: добавить/подправить тесты, покрывающие кейсы.
4. Ручной код-ревью (читаемость и дизайн)
- Оценить ясность, модульность, соответствие стилю кодирования, наименование переменных и функций.
- Проверять архитектуру: разделение ответственности, уровни абстракций, повторное использование.
- Ищем «code smells»: дублирование, большие функции, глубину вложенности.
5. Тесты и покрытие
- Оценить качество тестов: юнит/интеграционные, позитивные/негативные кейсы.
- Целевой минимум покрытия: $\ge 70\%$ (можно повышать до $\ge 80\%$ для продвинутых работ).
6. Производительность и безопасность (по необходимости)
- Оценить асимптотику критичных участков, утечки памяти, уязвимости.
- Простые пороговые проверки: сложность критичной функции, потребление памяти.
7. Отчёт и доработка
- Сформулировать короткий набор правок и багов.
- Студент вносит исправления и отвечает на комментарии; повторный обзор при необходимости.
Критерии оценки (на что конкретно смотреть)
- Корректность: соответствует ли результат ТЗ, обрабатываются ли граничные случаи.
- Надёжность: устойчивость к ошибкам ввода, обработка исключений.
- Читаемость: ясные имена, небольшие функции, комментирование там, где логика неочевидна.
- Структура и дизайн: модульность, слои, соблюдение принципов SRP/DRY.
- Код-стиль и форматирование: единообразие, автопроход линтера/форматтера.
- Тесты: полнота, качество ожиданий, воспроизводимость.
- Документация: README, комментарии API, инструкции запуска и проверки.
- Производительность: алгоритмическая сложность, нет явных узких мест.
- Безопасность: валидация внешних данных, избегание инъекций, управление секретами.
- Оригинальность/плагиат: код должен быть самостоятельным.
Практические пороговые рекомендации
- Цикломатическая сложность функции: $\mathrm{CC}\le 10$.
- Длина функции: желательно $\le 200$ строк; предпочтительнее $\le 50$.
- Покрытие тестами: минимум $\ge 70\%$ (для продвинутых заданий $\ge 80\%$).
- Не должно быть ошибок сборки/тестов: $0$ критических ошибок.
Чек-лист для быстрого просмотра (студенту перед сдачей)
- Код собирается и запускается по инструкции.
- Все тесты проходят.
- Линтер/форматтер не выдаёт ошибок.
- README описывает запуск и примеры.
- Нет «магических чисел», плохих имён, длинных функций.
- Изменения оформлены в коммитах с осмысленными сообщениями.
Роль преподавателя vs студента при оценке
- Преподаватель: фокус на соответствии ТЗ, глубине понимания, архитектуре, адекватности тестов и академической честности; даёт направленные комментарии.
- Студент: заботится о воспроизводимости, автоматизации проверок (CI), читаемости и покрытии; корректно отвечает на комментарии и документирует изменения.
Пример рубрики (примерное распределение веса)
- Корректность и требования: $40\%$ - Тесты и покрытие: $20\%$ - Стиль и читаемость: $15\%$ - Документация и инструкции: $10\%$ - Архитектура и модульность: $10\%$ - Производительность/безопасность: $5\%$
Короткое резюме: при review сначала убедитесь в воспроизводимости и корректности, затем автоматизируйте проверки, потом анализируйте читаемость и дизайн; используйте чек-листы и пороги (например, $\mathrm{CC}\le 10$, покрытие $\ge 70\%$), давайте конструктивный feedback, студенты должны дорабатывать и документировать изменения.