Skip to content

assignment.md

Latest commit

 

History

History
101 lines (73 loc) · 7.46 KB

assignment.md

File metadata and controls

101 lines (73 loc) · 7.46 KB

Задание на воркшоп: база + 2 фичи (без простоя)

У вас есть большая заранее подготовленная кодовая база (моно‑репозиторий). Для воркшопа в ней уже созданы две feature‑ветки (по одной на каждого участника пары). Вы будете вести 2 PR параллельно без простоя:

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

PR уже «заготовлены» в виде веток — вам не нужно придумывать изменения с нуля. Ветки называются feature-1 и feature-2 (или как скажет преподаватель).

Что нужно сделать (результат)

Для каждого PR:

  • 6–10 комментариев с метками BLOCKER / NON-BLOCKING / QUESTION / SUGGESTION;
  • 1 итоговый комментарий-резюме (шаблон в templates.md);
  • решение: Approve или Request changes (лучше честно блокировать риск, чем «протаскивать» merge).
  • CI Checks/Actions в PR просмотрены и интерпретированы (что упало/почему/какой риск). В CI есть:
    • тесты;
    • линтер/форматер (если найдены задачи в Gradle/Maven);
    • статический анализ/метрики сложности (job Static analysis & complexity, отчёт lizard-report в артефактах).

Механика (важно)

  • После создания PR обязательно добавьте напарника в Reviewers (справа в PR → Reviewers → выбрать пользователя → Request review).
  • Ревью начинайте не со стиля, а по порядку из cheatsheet.md.
  • Сначала каждый делает self‑review своего PR (см. шаги ниже), затем — ревью PR напарника.
  • После ревью вы правите ветку напарника и закрываете замечания в его PR (у вас есть права пушить в общий репозиторий пары).

Пошаговая инструкция

Чеклист перед стартом

  • Примите assignment в GitHub Classroom.
  • Откройте репозиторий пары.
  • Договоритесь, кто берёт ветку feature-1, кто — feature-2.

0) Подготовка (2–3 минуты)

  • Примите assignment в GitHub Classroom и откройте репозиторий вашей пары.
  • Договоритесь, кто какой PR создаёт:
    • студент A создаёт PR из feature-1 в main;
    • студент B создаёт PR из feature-2 в main.
    • Если ветки называются иначе — следуйте инструкции преподавателя.

1) Создайте PR (каждый — свой) (5–7 минут)

В GitHub:

  • Pull requests → New pull request
  • base: main ← compare: feature-1 (или ваша ветка)
  • Create pull request

Что написать в описании PR (коротко, 5–10 строк):

  • Контекст: что меняется и зачем.
  • Ссылка на спецификацию фичи: specs/feature-1.md или specs/feature-2.md.
  • Как проверить (локально/CI).
  • Риски/ограничения (если видите).

Подсказки по структуре — в templates.md (а также может быть автоподстановка шаблона PR).

2) Self‑review своего PR (обязательно) (5–7 минут)

Цель: пройти алгоритм ревью по cheatsheet.md на своём PR и зафиксировать риски до внешнего ревью.

Сделайте:

  • откройте свой PR → Files changed и пройдите чеклист;
  • добавьте 1 комментарий в PR (Conversation) с заголовком SELF-REVIEW:
    • 3 главных риска/вопроса (по категориям);
    • что вы бы проверили тестами/в CI;
    • что вы считаете blocker-ом, если это не исправить.

3) Добавьте напарника в Reviewers (обязательно) (1 минута)

Откройте свой PR → справа блок Reviewers → добавьте напарника → нажмите Request.

4) Ревью PR напарника (15–20 минут)

Каждый ревьюит PR напарника:

  • Начните с описания PR и тестов/спеки (если есть), затем пройдите алгоритм из cheatsheet.md.
  • Пишите комментарии по формуле из templates.md и ставьте метки.
  • Завершите Review changes → выберите Comment (не Approve), если есть блокеры/вопросы.

5) Исправления в PR напарника (15–20 минут)

Каждый правит ветку напарника (PR, который вы только что ревьюили):

  • Откройте ветку напарника локально или редактируйте через GitHub (если удобно).
  • Исправьте 1–2 самых важных замечания (в идеале закрыть все BLOCKER‑ы, которые вы поставили).
  • Пушьте коммиты в ту же ветку напарника — PR обновится автоматически.
  • Если у вас нет прав пушить в ветку напарника, договоритесь: вы присылаете патч/коммит, напарник применяет и пушит.
  • В тредах комментариев отметьте, что исправили (или попросите автора проверить/принять решение).
  • Следите за CI (Actions/checks) и интерпретируйте, что именно упало (если упало).

6) Повторное ревью и решение (10–15 минут)

Каждый повторно смотрит PR напарника (после фиксов):

  • Проверяет, что блокеры закрыты и риск снижен.
  • Обновляет итог: Approve или Request changes.
  • Добавляет итоговое резюме по шаблону из templates.md.

Если вы закончили раньше

  • Возьмите дополнительную ветку/кейс (если выдан преподавателем).
  • Или улучшите качество ревью: перепишите 2–3 самых слабых комментария в сильные (по шаблону), добавьте 1–2 тест‑кейса «только текстом» в резюме.