Workshop: код-ревью как инженерная практика

Этот репозиторий — раздатка для студентов на занятии. Никакой подготовки заранее не требуется.

Кодовая база — один проект (одна сборка), внутри несколько модулей, которые используют общие модели и общую H2-БД.

Что вы делаете на воркшопе

Вы работаете в паре на заранее подготовленной кодовой базе и ведёте 2 PR параллельно (без простоя):

• у каждого есть свой PR (вы автор одной фичи);
• и есть PR напарника (вы ревьюер);
• после ревью вы исправляете замечания в PR напарника (пушите коммиты в его ветку).

Ваша цель — не «найти стиль», а принять инженерное решение о merge через оценку рисков.

Инструкция задания: assignment.md Ветки для PR: feature-1 и feature-2 (если преподаватель не сказал иначе).

Где смотреть теорию

• Быстрая шпаргалка на занятие: cheatsheet.md
• Шаблоны для комментариев и резюме: templates.md
• Полная теория (опционально, если успеете): longread.md
• Спецификации фич (что должно получиться): specs/README.md

Правила ревью

• Идите по фиксированному порядку (см. cheatsheet.md), стиль — в самом конце.
• Каждый комментарий: что вижу → риск → почему важно → что предлагаю.
• Используйте метки в начале комментария: BLOCKER, NON-BLOCKING, QUESTION, SUGGESTION.

Что нужно сдать (на каждый кейс)

В GitHub PR (как ревью):

• 6–10 комментариев с метками;
• 1 итоговый комментарий-резюме (шаблон в templates.md);
• решение: Approve или Request changes (если сомневаетесь — выбирайте Request changes и объясните риски).

Как работать в GitHub (кратко)

• Примите assignment в GitHub Classroom (ссылка будет от преподавателя) и откройте репозиторий вашей пары.
• Создайте 2 PR из подготовленных веток в main (кто какую ветку берёт — по инструкции преподавателя).
• В каждом PR добавьте напарника в Reviewers и нажмите Request review.
• Нажмите Files changed и начните ревью с описания PR и тестов/спеки (если есть).
• Нажмите Review changes → выберите Comment/Approve/Request changes.
• Смотрите статус CI вверху PR и вкладку Actions: падающие проверки — это сигнал риска, который нужно интерпретировать (что упало, почему, какой риск). В CI есть тесты, линтер (если настроен) и метрики сложности (job Static analysis & complexity, отчёт — артефакт lizard-report).

Как запустить проект локально (опционально)

Если хотите проверить поведение руками, можно поднять приложение без MVC: Spring используется только для запуска, DI и JdbcTemplate.

• Запуск: mvn -pl app spring-boot:run
• Тесты: mvn test