Как выбрать между быстрым решением и правильной архитектурой

Быстрый фикс может вернуть сервис в строй за час, а «правильное» решение потребует недели. Проблема начинается, когда временный патч попадает в продакшен без срока жизни, владельца и расчёта цены. Ниже — критерии, которые помогают выбрать между скоростью и качеством для конкретной задачи, а не для абстрактной идеальной системы.

Сначала отделите аварию от обычной разработки

Один и тот же дефект требует разных решений в зависимости от контекста. Если пользователи не могут оформить заказ, сервис отдаёт ошибки или данные перестали записываться, приоритетом становится восстановление доступности. Если проблема не влияет на текущих пользователей, у команды больше пространства для проектирования.

Перед выбором зафиксируйте четыре факта:

• какой ущерб возникает прямо сейчас: простой, потеря заказов, дублирование операций или только неудобство для команды;
• сколько пользователей и операций затронуто;
• есть ли безопасный способ откатить изменение;
• какой крайний срок нельзя нарушить и почему.

Если система падает, быстрый ограниченный фикс часто оправдан. Но он должен быть именно этапом восстановления, а не молчаливой заменой полноценного решения.

Быстро — это не «написать меньше кода». Быстро — значит сократить время до безопасного результата, включая проверку и откат.

Критерии выбора

1. Цена ошибки

Сравнивайте не время разработки, а последствия неправильного решения. Ошибка в цвете кнопки и ошибка в расчёте платежа не могут оцениваться одной шкалой.

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

2. Обратимость

Обратимое изменение можно отменить без потери данных и длительного простоя. Необратимое — например массовая миграция или удаление записей — требует более тщательной подготовки, даже если само действие занимает несколько минут.

Задайте два вопроса: можно ли вернуть код и можно ли вернуть состояние данных. Ответ «да» только на первый вопрос не делает изменение безопасным.

3. Срок жизни решения

Патч на несколько часов и патч, который будет работать полгода, — разные инженерные решения. У временного варианта должны быть владелец, дата пересмотра и условие удаления. Без этого технический долг — обязательство команды исправить упрощение позже, заплатив временем, риском или сложностью поддержки. — начинает расти незаметно.

4. Стоимость поддержки

Оцените, кто будет объяснять решение через месяц. Если следующий разработчик должен помнить неочевидное исключение, ручной порядок действий или особое значение настройки, быстрый вариант уже имеет постоянную цену.

Признаки высокой стоимости поддержки:

• поведение нельзя проверить автоматическим тестом или метрикой;
• решение зависит от одного человека;
• ошибка проявляется только в продакшене;
• для восстановления нужен ручной доступ к базе или серверу;
• в коде появляются комментарии «не удалять» без объяснения причины и срока.

Четыре рабочих варианта

Как принять решение за одну встречу

Не начинайте с обсуждения того, что «красивее». Сначала заполните короткую карточку решения. Её можно хранить рядом с задачей или в ADR — записи архитектурного решения с контекстом, выбранным вариантом и последствиями..

1. Опишите проблему одним предложением. Не «нужно переписать модуль», а «при повторной оплате создаются две операции».
2. Назовите ограничение. Например, релиз сегодня, отсутствие тестового стенда или необходимость сохранить совместимость с текущим клиентом.
3. Посчитайте допустимый ущерб. Укажите не только деньги, но и количество пользователей, время простоя, объём ручной работы и риск потери данных.
4. Запишите минимум два варианта. Один быстрый и один устойчивый. Если обсуждается только один путь, цена альтернативы неизвестна.
5. Проверьте откат. Опишите, кто и какой командой, настройкой или релизом отменит изменение. Если такой план нельзя сформулировать, решение ещё не готово.
6. Назначьте следующий шаг. Для патча это может быть задача на удаление временного кода, для переработки — эксперимент или миграция части трафика.

На выходе должна появиться не фраза «выбрали быстро», а конкретная запись: какой риск принимаем, на какой срок и по какому показателю поймём, что пора менять подход.

Когда быстрый вариант действительно правильный

Патч разумен, если одновременно выполняются несколько условий:

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

Не обязательно ждать идеальную архитектуру, чтобы снизить риск. Например, можно временно ограничить обработку одного типа запросов, пока команда готовит корректную модель данных. Важно не выдавать ограничение за исправление причины.

Когда «сделаем потом» становится плохим решением

Отложенная переработка опасна, если временный код находится на критическом пути: в авторизации, оплате, списании остатков, обработке персональных данных или восстановлении после сбоя. Там стоимость забытых исключений растёт вместе с объёмом данных и числом зависимых сервисов.

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

Что ломается при выборе «быстро»

Патч не имеет владельца

Задача «починить потом» не принадлежит никому. Добавьте ответственного и дату проверки. Если срок неизвестен, привяжите пересмотр к событию: следующему релизу, миграции или достижению конкретного объёма нагрузки.

Проверяют только счастливый сценарий

Исправление работает для одного запроса, но ломается при повторе, тайм-ауте или частично недоступной зависимости. Минимальная проверка должна включать повторную операцию, ошибку внешнего сервиса и откат.

Метрика не показывает цену решения

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

Переработка расползается

«Сделать правильно» иногда превращается в переписывание всей системы. Ограничьте первый этап: один поток, один тип данных или один сервис. Сначала докажите, что новое решение снижает конкретный риск, а не просто выглядит чище.

Как измерить результат

Если у команды нет замеров, не подставляйте выдуманные цифры. Зафиксируйте базовую линию перед изменением: число запросов в минуту, долю ошибок, p95 задержки, количество повторных операций, время восстановления и объём ручной обработки. Снимите те же показатели после релиза на сопоставимом интервале и при близкой нагрузке.

Для быстрого патча особенно важны три точки: результат сразу после выката, состояние через несколько часов и состояние после следующего пикового периода. Если временный путь не имеет наблюдаемого срока жизни, он почти неизбежно станет постоянным.

Что делать дальше

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

Для систем, которые часто переживают инциденты, следующим шагом стоит настроить журнал архитектурных решений и единый шаблон постмортема. Это сокращает повторные споры: команда видит, почему был выбран быстрый путь и какое условие должно запустить полноценное исправление.