Implementation Plan — міст між доказами та кодом
Investigation Note показує, де проблема і що підтверджено. Implementation Plan відповідає на інше питання: у якому порядку безпечно змінювати систему та як довести результат.
План має бути самодостатнім для реалізації, але коротшим за всю історію дослідження. Його потрібно погодити з людиною до редагування коду.
| Частина плану | Зміст |
|---|---|
| Мета | Який спостережуваний результат має змінитися |
| Scope | Компоненти, сценарії та тести, що входять у роботу |
| Non-goals | Що навмисно залишається без змін |
| Точки змін | Підтверджені або ймовірні файли й модулі |
| Послідовність | Кроки в порядку, який зменшує ризик |
| Ризики | Побічні ефекти та спосіб їх контролю |
| Verification | Команди, тести й ручні сценарії з очікуваним результатом |
| Stop і rollback | Коли зупинитися та як повернутися до стабільного стану |
Scope і non-goals захищають задачу
- Локальний баг не є приводом одночасно переробляти UI.
- Не змінюйте успішні сценарії без acceptance criterion.
- Не торкайтеся сторонньої бізнес-логіки лише тому, що вона виглядає неідеально.
- Не поширюйте локальний фікс на всю error architecture без окремого рішення.
- Поява shared-модулів або нових великих підзадач — сигнал повернутися до плану.
Ризик має мати контроль
Task risk list не повинен бути переліком абстрактних страхів. Для кожного ризику вкажіть, що може піти не так і якою перевіркою це буде помічено.
Для checkout це можуть бути зміна поведінки непорожнього замовлення, залежність frontend від error format, побічний вплив на інші виклики calculateTotal() або необхідність перебудови загальної схеми помилок.
| Ризик | Контроль |
|---|---|
| Непорожній checkout зміниться | Regression test для валідного замовлення |
| Frontend залежить від формату помилки | Перевірка API-контракту й узгодженого response body |
| Shared pricing logic має інші виклики | Пошук усіх використань і targeted tests |
| Потрібна широка зміна error schema | Stop condition і рішення власника контракту |
Verification повинна бути вимірюваною
- Назвіть конкретний regression або targeted test.
- Вкажіть команду, яку потрібно запустити.
- Опишіть очікуваний статус, тіло відповіді або інший observable result.
- Перевірте сусідні сценарії, які повинні залишитися незмінними.
- Для ручної перевірки задайте точний запит, input і очікувану відповідь.
- Розділіть машинні критерії завершення та рішення, яке залишається за людиною.
Stop conditions і rollback
- Зупиніться, якщо потрібна загальна зміна формату помилок.
- Зупиніться, якщо доменне правило виявилося неоднозначним.
- Зупиніться, якщо зачеплено shared pricing logic поза погодженим scope.
- Зупиніться, якщо diff виходить у неповʼязані модулі.
- Зупиніться, якщо падають тести, не повʼязані з початковим сценарієм.
- Для малої задачі прагніть одного логічного rollback без міграцій схеми або даних.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush