Код-ревью - получаем и исправляем комментарии

Что такое код-ревью

• Процесс проверки кода старшим разработчиком
• Ревьюер оставляет комментарии к коду
• Это не критика — это обучение и улучшение качества
• Даже опытные разработчики получают комментарии

Виды ревью на GitHub

При завершении ревью ревьюер выбирает:

Comment — просто комментарии без статуса Approve — код отличный, можно сливать в main Request changes — нужны доработки (наш случай)

Получение комментариев

Где увидеть:

• На странице PR → вкладка Conversation
• Уведомление: "[Имя] requested changes"
• Общий комментарий + ссылка "View changes"
• В Files changed — комментарии к конкретным строкам

Уведомления:

• Email от GitHub
• Уведомление в профиле GitHub (колокольчик)

Внесение правок

Где исправлять:

• В IntelliJ IDEA
• В той же ветке (KS-1-1-sum-calculation)
• НЕ создавать новую ветку!

Алгоритм:

1. Убедиться что в правильной ветке (индикатор внизу)
2. Открыть файл
3. Внести исправления согласно комментариям
4. Сохранить файл

Проверка:

• Файл окрасился в синий (Modified)
• Появился в панели Commit
• Можно посмотреть diff (старая vs новая версия)
• Обязательно запустить код и проверить работоспособность!

Сообщение коммита с правками

Структура:

PREFIX-НОМЕР-НОМЕР краткое описание правок

Примеры хороших сообщений:

• KS-1-1 add comments and update output
• KS-1-1 fix review comments
• KS-1-1 update code after review
• PROJ-23 fix naming and add validation

Принцип:

• Префикс остается тот же (та же задача!)
• Описание: что исправлено
• Кратко и понятно

Commit and Push правок

1. Проверить стейдж: Файлы отмечены галочками
2. Написать сообщение: префикс + описание правок
3. Commit and Push: Отправить в ту же ветку
4. Подтверждение: Push to origin/ваша-ветка
5. Нажать Push

Результат: Коммит на GitHub в той же ветке

Автоматическое обновление PR

Что происходит:

• GitHub отслеживает ветку
• Новый коммит → автоматически подтягивается в PR
• Обновляется история на вкладке Conversation
• Обновляется список коммитов (вкладка Commits)
• Обновляется diff (вкладка Files changed)

В истории PR:

[Ваше имя] added 1 commit
KS-1-1 add comments and update output

Вы НЕ создаете новый PR! Используется тот же самый.

Уведомление ревьюера

После правок обязательно написать комментарий:

Примеры:

• "Исправил согласно комментариям. Прошу проверить."

• "Fixed. Ready for review."

• "Внес правки. Готово к повторной проверке."

Где писать:

• Вкладка Conversation
• Поле "Write a comment"
• Нажать Comment

Ревьюер получит уведомление.

Цикл правок (итерации)

Алгоритм:

1. Ревьюер: Request changes (оставляет комментарии)
2. Вы: Исправляете код в той же ветке
3. Вы: Коммитите и пушите
4. GitHub: PR автоматически обновляется
5. Вы: Уведомляете ревьюера комментарием
6. Ревьюер: Проверяет снова

Повторять 2-6 до одобрения.

Завершение:

• Ревьюер ставит Approve

• Задача принята!

• Можно сливать PR в main

Важные правила

⚠️ НЕ создавайте новый PR:

• Один PR на одну задачу
• Все правки в той же ветке
• GitHub сам обновит PR

⚠️ Всегда проверяйте код:

• Запустите перед коммитом
• Убедитесь что работает
• Не коммитьте сломанный код

⚠️ Уведомляйте ревьюера:

• После правок напишите комментарий
• Иначе ревьюер может не знать что вы закончили

Префикс не меняется:

• Та же задача = тот же префикс
• Только описание меняется (что исправлено)

Просмотр обновленного PR

Вкладка Conversation:

• История всех действий
• Комментарии ревьюера и ваши ответы
• Хронология коммитов

Вкладка Commits:

• Все коммиты задачи (первый + правки)
• В порядке создания

Вкладка Files changed:

• Финальный diff
• ВСЕ изменения с момента создания ветки
• Это то, что будет влито в main

Статус PR после правок

• Остается Open (открыт)
• Ждет повторной проверки ревьюера
• После Approve изменится на готов к слиянию

Реальный процесс в командах

Один цикл правок — хорошо Несколько циклов — нормально Много циклов — значит учитесь многому!

В реальных командах:

• Может быть 2-3 цикла правок
• Это нормальная практика
• Никто не пишет идеальный код с первого раза