Скил systematic-debugging — сначала первопричина, потом исправление

Самый надёжный способ потратить три часа на часовой баг — начать чинить до того, как понял суть. Скил systematic-debugging предотвращает именно это. Его главный закон: никаких исправлений, пока не установлена первопричина.

Правило действует во всех ситуациях, перечисленных в скиле, — упавшие тесты, баги на продакшне, ошибки сборки, проблемы с производительностью, интеграционные сбои. Оно не смягчается под давлением срочности. Скил прямо указывает: систематическое исследование быстрее, чем угадывание, — а не медленнее.

Четыре фазы

Скил организует работу в четыре последовательные фазы. Каждая должна завершиться до начала следующей.

Фаза 1 — исследование первопричины. Прочитать сообщение об ошибке полностью: трассировку стека, номера строк, коды. Воспроизвести проблему стабильно. Проверить, что изменилось недавно. Когда система состоит из нескольких компонентов, нужно добавить диагностическую инструментацию на каждой границе — залогировать входящее, залогировать исходящее, убедиться, что конфигурация propagates. Один прогон собирает доказательства, анализ идёт после.

Фаза 2 — анализ паттернов. Найти рабочий код в той же кодовой базе, похожий на сломанный. Сравнить оба варианта и перечислить каждое отличие, как бы мало оно ни казалось. Понять, от чего зависит рабочая версия, чего не хватает сломанной.

Фаза 3 — гипотеза и проверка. Сформулировать одну конкретную гипотезу: «Я думаю, что X — первопричина, потому что Y» — и внести минимально возможное изменение для её проверки. Одна переменная за раз. Если изменение не подтверждает гипотезу, формируется новая. Никакого накопления правок.

Фаза 4 — реализация. Сначала создать падающий тест-кейс, затем устранить выявленную первопричину одним изменением, затем проверить результат. Если три отдельных исправления не решили проблему, скил предписывает остановиться и поставить под сомнение архитектуру — вместо четвёртой попытки.

Лимит трёх попыток

Лимит трёх попыток — одно из самых конкретных правил скила. Когда каждая исправленная попытка открывает новую проблему в другом месте или каждая правка требует масштабного рефакторинга — это признак архитектурной проблемы, а не упущенной детали. В этот момент правильное действие — обсудить архитектуру, а не продолжать патчить.

Красные флаги

Скил перечисляет конкретные фразы и импульсы, сигнализирующие о нарушении процесса: «быстро пофиксим сейчас, разберёмся потом», «добавим несколько изменений и прогоним тесты», «до конца не понимаю, но, может, сработает». Каждый — повод остановиться и вернуться к фазе 1. Данные из скила — 15–30 минут при систематической отладке против 2–3 часов при случайных правках, 95% корректных исправлений с первого раза против 40% — отражают разницу между уважением к красным флагам и их игнорированием.

Скил systematic-debugging работает в паре со скилом testing (создание падающего тест-кейса в фазе 4) и со скилом utilities для диагностической инструментации в шелле. Общую картину даёт пост что такое Datarim.