diagnosing-bugs

Этот скилл Matt Pocock задаёт дисциплину для сложных багов и деградаций производительности. Его главный тезис — сначала построить короткий feedback loop с чётким сигналом pass/fail, который действительно может стать красным на заявленной проблеме. Без такого сигнала чтение кода и рассуждения о вероятной причине не заменяют воспроизводимую проверку. Скилл предлагает пропускать отдельные фазы только с явным обоснованием, а основной объём внимания отдавать созданию теста или другого запускаемого воспроизведения. В качестве вариантов перечислены failing test на нужной границе, curl или HTTP-скрипт, CLI-вызов с fixture, headless-браузер с проверками DOM, console и network, replay сохранённого trace, небольшой throwaway harness, property или fuzz loop, bisection harness, differential loop и, в крайнем случае, структурированный HITL bash-loop. Первым делом нужно сделать loop быстрым, точным и детерминированным. После первого рабочего варианта скилл предлагает ускорить подготовку, убрать несвязанный startup, усилить assertion до конкретного симптома, зафиксировать время и seed и изолировать файловую систему или сеть, если это возможно. Для недетерминированной ошибки цель — не обязательно получить идеальный единичный repro, а поднять частоту воспроизведения: повторять триггер много раз, параллелить запуски, сужать окно времени и добавлять управляемую нагрузку. Петля считается готовой, когда можно назвать уже выполненную команду, которая проходит через фактический код проблемы, проверяет именно пользовательский симптом, детерминированна, выполняется без человека и завершается за секунды, а не за минуты. Затем выполняется воспроизведение и минимизация. Нужно убедиться, что виден именно описанный пользователем режим, проверить повторяемость, записать точный текст ошибки, неверный результат или задержку и убирать входы, вызовы, конфигурацию и шаги по одному. Минимальный сценарий сохраняет только load-bearing элементы: удаление любого из них должно вернуть проверку в зелёное состояние. До инструментирования скилл требует сформулировать три-пять ранжированных и проверяемых гипотез. Для каждой полезно заранее указать предсказание: какое изменение устранит симптом или усилит его. Это отделяет эксперимент от впечатления и позволяет менять одну переменную за раз. Инструментирование начинается с debugger или REPL, затем используются точечные логи на границах, которые различают гипотезы. Секреты в командах, выводе и артефактах нужно редактировать, заменяя их на <REDACTED>; креденшелы остаются только в переменных окружения. Временные отладочные логи получают уникальный префикс, чтобы затем удалить их одним поиском. На стадии исправления минимальный repro превращается в regression test на правильной архитектурной границе, сначала наблюдается его падение, затем применяется фикс и проверяется зелёный результат; после этого исходный, неупрощённый сценарий запускается повторно. Если подходящей границы тестирования нет, это нужно явно зафиксировать как архитектурное ограничение, а не создавать ложную уверенность поверх слишком мелкой проверки. Завершение включает повтор оригинального loop, проверку regression test, удаление всех debug-инструментов и throwaway-прототипов и вопрос о том, что могло бы предотвратить дефект. Скилл не обещает автоматического определения причины: его ценность в том, что каждый следующий шаг привязан к наблюдаемому сигналу.