Nodumb

nodumb

Код — дешёвая часть ошибки. Дороже всего уверенно делать не то, не там или на основании факта, которого никто не проверял.

Перед продолжением ответить на три вопроса:

1. Ту ли задачу решаем? Запрос часто приходит уже в форме решения.
2. В том ли масштабе решаем? Локальная правка может скрывать общее решение, а общий слой может оказаться лишним.
3. Есть ли новый применимый факт? Следующая попытка на тех же данных обычно повторяет предыдущую.

Не проходить весь скилл каждый раз. Выбрать нужный режим по текущей ситуации. Перед запуском режима назвать, какой его результат способен изменить следующий шаг; если такого результата нет, пропустить режим.

Как выбрать источник факта

Искать факт там, где находится источник истины о проверяемом поведении. Если его определяет текущий проект — сначала наблюдать код, состояние, логи, тесты и историю. Если источник истины находится вне текущего репозитория — проверить первичный источник для точной версии зависимости, платформы или сервиса: официальную документацию, changelog либо issue-трекер владельца.

Внешний поиск формулировать через контракт, версию и точный симптом, а не через общий запрос «как исправить». Найденное утверждение остаётся гипотезой, пока локальный пробник или воспроизведение не подтвердят его применимость к этому проекту. Перед второй правкой без нового факта обязательно сменить источник данных; подробный выбор — references/stuck-new-data.md.

1. Перед кодом

Применять, если неверное направление стоит часов, результат трудно отменить или непонятно, зачем предложено конкретное решение.

• Сформулировать задачу от пользователя, а не от интерфейса или кода.
• Если постановка останется в тикете, плане или другом долговечном артефакте, разделить проверенное и предположенное. Для утверждений, определяющих направление решения, указать источник проверки.
• Новый факт считать основанием решения только внутри проверенной области применимости. Если меняются сущности, предпосылки, условия, способ измерения, база, шкала или модель, рассматривать перенос как отдельный вывод: обосновать его дедуктивно через сохранение предпосылок и отношений, эмпирически в целевом контексте или обоими способами. Без проверки назвать вывод для новой модели гипотезой.
• Гипотезу, которую можно безопасно проверить сейчас по доступному коду, истории, документации или командой, проверить до записи. Если нельзя — назвать её гипотезой и указать, что нужно для проверки: недоступные данные, человеческое участие или расширение скоупа.
• Вопрос, зависящий от человеческого выбора, назвать несогласованным решением, а не гипотезой. Если ответ создаёт развилку, записать ветки и условие выбора.
• Проверить, как человек справляется сейчас и что должно стать лучше.
• Назвать признак успеха, который можно наблюдать.
• Найти самую дорогую развилку и дать одну рекомендацию.
• Если предлагаемое решение меняет архитектуру, модель продукта или несколько независимых сценариев, сначала измерить размер проблемы: сколько сценариев сломано, как часто это происходит и как человек справляется сейчас.
• Сравнить самое дешёвое решение с предлагаемым. Для каждого назвать пользовательский результат, объём изменения и риск для существующего поведения. Если результат одинаков — выбрать дешёвое. Дорогое оправдано, только если дешёвое оставляет конкретные подтверждённые случаи нерешёнными.
• Перед возвратом к ранее отвергнутой архитектурной идее проверить решения и память проекта. Назвать новый факт, из-за которого прежнее решение больше не действует; без нового факта не открывать развилку заново.
• Явно согласовать только необратимое решение, существенную неопределённость или изменение скоупа. В остальных случаях назвать допущение и продолжить.
• Данные, права и публичное поведение считать усилителями цены ошибки, а не автоматическими причинами вопроса. Остановиться для человеческого выбора, только если нужно определить новую политику доступа, допустить потерю или миграцию данных либо изменить действующий публичный контракт. Если поведение уже однозначно задано проверенным контрактом, исполнить его и продолжить.

Вопросы для разбора — references/before-code-questions.md. Формат плана — references/plan-format.md.

2. Перед массовой правкой

Применять, если текущая задача требует одинаково менять несколько независимых мест.

• Сначала определить фазу продукта. В прототипе и MVP не строить систему ради чистоты кода: важнее быстро проверить гипотезу.
• В устоявшейся части продукта посчитать места и значения до правки.
• Проверить, действительно ли повторения имеют одну причину меняться.
• Если отсутствие общего места уже мешает текущей работе — вынести минимальный источник: контракт, токен, компонент, адаптер или скрипт.
• Если не мешает или причины разные — оставить решения локальными.
• Начать с одного небольшого участка и проверить его до массового переноса.

Не заводить дизайн-систему, библиотеку компонентов или другой слой просто «на будущее». Нормальный результат проверки — общий слой пока не нужен.

Подробности: references/scaling-phases.md для выбора фазы, references/scaling-triggers.md для подсчёта и references/scaling-build-system.md для системы значений. Исходный случай — references/scaling-postmortem.md.

3. Когда отладка встала

Перед второй правкой получить новый факт. После двух неудачных правок считать, что прежний метод исчерпан.

• Сначала воспроизвести симптом на той ветке, где он возникает.
• Сформулировать гипотезу так, чтобы проверка могла её опровергнуть.
• Сменить источник данных: лог, дамп состояния, минимальный пример, история изменений, документация, issue-трекер или рабочий аналог.
• Только после нового наблюдения менять код.
• Если починка была объявлена, но не подтвердилась, сначала заменить способ проверки, а не делать ещё одну правку.

Способы получить новые данные — references/stuck-new-data.md. Вопросы к самой постановке — references/stuck-question-premise.md. Разбор после долгого затыка — references/stuck-postmortem.md.

Как отвечать

Начать с рекомендации. Коротко назвать, что известно, где главная неопределённость, что делать дальше и чем проверить результат. Не превращать это в обязательный шаблон для мелких задач.