Технічний борг і static signals

Як обмежити technical-debt discovery пʼятьма evidence-backed static signals.

Technical debt signal — це індикатор, не доказ дефекту

Static signal допомагає вирішити, де потрібне глибше дослідження. Він не доводить сам по собі наявність bug, неправильного дизайну або необхідність refactor. Наприклад, TODO, низьке coverage чи частий Git churn можуть мати законне пояснення — тому signal потрібно поєднати з контекстом і потенційним впливом.

Для одного discovery-циклу обмежте набір максимум пʼятьма найсильнішими сигналами. Кожен signal має бути однією думкою у форматі: область + evidence + ризик + наступний крок.

П’ять класів сигналів

Signal	Що перевіряє	Межа висновку
Source structure	складність, дублювання, legacy paths, великі модулі	не означає, що код має defect
Tests and coverage	відсутні сценарії, слабкі assertions, coverage gaps	coverage не дорівнює якості поведінки
Change history and ownership	Git churn, відсутній owner, часті emergency changes	часті зміни можуть бути очікуваним розвитком
Configuration and build	warnings, precedence, feature flags, dependency drift	warning потребує класифікації та впливу
Known reports	TODO/FIXME, incidents, user reports, discrepancy	report — input для перевірки, не root cause

Приклади evidence-backed signals

mrr-engine/MrrFormulas.java має Git churn, який потрібно зіставити з формулою, тестами та reported discrepancy;
subscriptions/SubscriptionService.java треба перевірити разом із tests/integration/MrrSnapshotIT.java, а не робити висновок лише з назви сервісу;
legacy/OldBillingUtils.java — сигнал широкого впливу, якщо його викликають кілька flows, але слабкі тести залишають поведінку невідомою;
PaymentRetryService.java і reporting/ReportCsvFormatter.java потребують різних risk hypotheses: recovery грошей та стабільність зовнішнього формату;
application.yml, JaCoCo report і TODO/FIXME search можуть пояснити configuration, coverage та maintenance signals.

Команди — лише джерела, не автоматичний verdict

Результат кожної команди запишіть із датою, scope і обмеженням. Не вигадуйте coverage percentage або кількість warning, якщо команда фактично не запускалася. Гіпотезу позначайте словом «гіпотеза», а наступним кроком робіть конкретну перевірку: відкрити test, простежити caller, знайти owner або виконати manual scenario.

Приклади збору signals без редагування

git log --since="1 year ago" --oneline -- mrr-engine/MrrFormulas.java
./gradlew test jacocoTestReport
grep -R "TODO\|FIXME" -n legacy/

Як скоротити signal log до корисного набору

Зберіть широкий список можливих indicators.
Відкиньте сигнали без зрозумілого evidence anchor.
Обʼєднайте дублікати, щоб одна думка не зʼявлялася кілька разів.
Залиште максимум пʼять сигналів із найвищим поєднанням впливу та невизначеності.
Для кожного запишіть ризик і один наступний крок.
Перенесіть наслідки до RISK_MAP.md, не перетворюючи signal log на backlog усіх бажаних refactors.

Канонічне джерело уроку · JavaRush

Відкрити матеріал JavaRush