Модуль 9 · урок 9 з 9
Практика модуля
Цей модуль не робиться в кінці — він робиться протягом усіх інших. Тому практика тут інша: не «напиши код», а «переконайся, що історія репозиторію виглядає так, ніби її вів інженер, а не студент напередодні здачі».
То цей модуль уже майже закритий, і кроки нижче — це просто перевірка. Якщо ні — почни з кроку 1 сьогодні, і за два тижні решта набереться сама. Наздогнати заднім числом не вийде: сенс саме в звичці.
КРОК 1Дошка із задачами
Заведи задачі на те, що лишилось: по одній на модуль або на функцію. GitHub Issues + Projects достатньо. Правило одне: перед роботою переводиш задачу в Active, після мерджу — в Closed. Дошка, яка відображає реальність, — це вся суть цілі з Azure Boards.
КРОК 2Гілка на задачу
Жодного коміту прямо в main. Гілка називається feature/12-status-filter —
тип, номер задачі, короткий опис. Створюється від свіжого main, живе
один-два дні, після мерджу видаляється.
КРОК 3Коміти за угодою
Кожен коміт — type(scope): subject в наказовому способі. Мінімум по одному
комітеві типів feat, fix, refactor, test,
chore — щоб ти реально відчув різницю, а не запамʼятав таблицю.
Хоча б в одному комітеві напиши тіло з поясненням чому.
КРОК 4Три справжні PR
Не один величезний, а три по 200–400 рядків. У кожному — опис за шаблоном із розділом «як перевірити», скріншот для видимих змін і чекбокси самоперевірки. Перед тим як відкрити — прочитай власний діф повністю. Половина зауважень ловиться саме тут.
КРОК 5Self-review наступного дня
Оскільки рецензента немає, зроби його роль сам — але не в той самий день.
Відкрий свій PR зранку й пройди його як чужий: назви, дублювання, чи є тести,
чи не забув takeUntilDestroyed. Знайдені зауваження запиши коментарями
в PR — так залишиться слід, який можна показати.
КРОК 6Пайплайн
Додай .github/workflows/ci.yml з чотирьох кроків: npm ci,
lint, test, build. Далі — зроби так, щоб він упав навмисно: додай any
в один файл і відкрий PR. Прочитай лог, знайди перший error, полагодь.
Це і є та сама навичка з формулювання цілі.
КРОК 7Конфлікт власноруч
Створи дві гілки, зміни в них один рядок по-різному, влий обидві. Вирішуй
через git rebase origin/main. Один раз спеціально скасуй усе через
git rebase --abort, щоб побачити: нічого не ламається. Після цього
конфлікти перестають бути страшними назавжди.
- Задачі ведуться на дошці й їхній стан відповідає реальності.
- У
mainнемає прямих комітів — усе через гілки й PR. - Історія комітів читається як журнал: типи, скоупи, наказовий спосіб.
- Є щонайменше три PR з описом і розділом «як перевірити».
- Пайплайн зелений, і ти хоча б раз лагодив його червоним.
- Ти вирішив конфлікт через rebase і знаєш, як скасувати.
Що сказати ліду на демо
«Репозиторій вівся за правилами з першого дня, а не приводився до ладу в кінці. Гілка на задачу, коміти за Conventional Commits, у тілі — причина, а не переказ дифа. PR тримав малими навмисно: на 200 рядків рецензент бачить логіку, на 900 — лише форматування. Пайплайн додав рано й один раз ламав спеціально, щоб пройти шлях від червоної галочки до причини в лозі. Конфлікти вирішую через rebase у своїй гілці, а відкат чогось влитого в main — тільки через revert.»
Три звички, які лишаться
- Коміт — це одна завершена думка.
- Rebase на свіжий main щодня, а не раз на тиждень.
- Читати власний діф перед відкриттям PR.
- «Потім розберу коміти» — не розбереш.
- Гілка, що живе два тижні, — гарантований конфлікт.
- Червоний CI, який «полагоджу завтра».
Це кінець плану. Девʼять модулів, 103 уроки — від блокової моделі до код-ревʼю. Далі роботу робить не читання, а застосування: візьми будь-яку функцію свого проєкту й проведи її через усі шари — типізацію, стан, форму, грід, доступність, тест, PR. Коли пройдеш цей шлях двічі свідомо, критерії з IDP закриються самі, бо вони описують саме це.