Business criticality і change risk — різні dimensions
Business criticality показує, наскільки болючим буде збій для користувачів або бізнесу. Change risk показує, наскільки легко саме запропонована зміна може порушити поведінку. Критичний flow може мати низький change risk для добре ізольованої правки, а другорядний модуль — високий change risk через shared utility та відсутність тестів.
Не зводьте ці dimensions до одного score. Додайте visible unknowns: невідомий owner, неперевірена configuration precedence або суперечливі docs впливають на рішення навіть тоді, коли business impact ще не оцінений.
Мінімальний запис risk map
| Поле | Що зафіксувати |
|---|---|
| Area | підсистема, flow або конкретний модуль |
| Business criticality | low / medium / high та чому це важливо |
| Change risk | low / medium / high і механізм можливого впливу |
| Risk categories | money, integration, data, dates, ownership, coverage тощо |
| Evidence | шляхи, тести, logs, Git history, reports |
| Missing checks | що саме ще не перевірено |
| Recommended action | конкретне рішення та наступний крок |
Приклади рішень, а не generic improve
mrr-engine / pause-resume MRR: high business criticality і high change risk; приблизно 25% coverage та можлива code/docs discrepancy — characterize behavior і перевірити owner до зміни;payments / retry recovery: high/high через money та external integration — зібрати recovery evidence і звузити scope до одного retry path;config / timezone + feature flags: medium/high — документувати precedence і виконати manual verification для дат та прапорців;legacy/OldBillingUtils.java: broad impact і weak tests — спочатку побудувати module/flow map, а не починати масовий refactor.
Операційні дії з risk map
Risk map має вести до рішення: що можна робити зараз, що потребує доказів, а що слід відкласти. Формулювання «покращити якість» без owner, scope і перевірки не є operational action.
- characterize current behavior для high/high flow;
- gather more evidence, якщо unknowns блокують оцінку;
- identify an owner для business rule або критичної інтеграції;
- document configuration precedence, якщо behavior залежить від кількох шарів;
- hold the change або narrow the scope, якщо evidence недостатньо;
- freeze changes чи defer work, якщо ризик перевищує готовність перевірок.
Git churn як допоміжний сигнал
У навчальному прикладі результатом може бути 11, але це потрібно трактувати лише як signal churn. Саме число без періоду, джерела та порогу не доводить ризик. Додайте його до evidence, порівняйте з іншими модулями й вирішіть, чи потрібне deeper discovery.
git log --since="1 year ago" --name-only --pretty=format: \
| grep 'mrr-engine/MrrFormulas.java' | wc -lКанонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush