Техдолг, ради техдолга - мертв
Остановись, хватит предлагать идеи:
- "А давайте возьмем другой брокер сообщений?"
- "А может на микросервисную архитектуру переедем?"
- " Давайте сменим state менеджер, там же вышел x3000ULTRAPROMAXNANO"
- "Давайте перепишем на Go/Rust, будет же быстрее"
- "Давайте заменим ORM/фреймворк, он лучше"
Все ваши идеи умрут, если вы не начнете думать, а зачем это надо?
В своих пет проектах или PoC, вы можете брать техдолг по причине:
- "Я смогу узнать новую доменную область/технологию"
Но на работе так это не работает.
На работе любая "техническая инициатива" (рефакторинг, миграция, замена либы, оптимизация, смена архитектуры) - это гипотеза. И она обязана отвечать на 3 вопроса:
1. Какую боль пользователя или продукта мы пытаемся решить?
2. Какая метрика это подтверждает?
3. Насколько станет лучше и сколько это будет стоить по капаситету?
Если тебе кажется, что после внедрения будет лучше, проведи эксперимент. Сформулируй:
- что станет лучше
- на сколько
- за какое время
- какие риски
- как вернуть все назад, если не гипотеза не сработала
Важно: улучшение одной метрики не должно статзначимо ухудшать другую.
Примеры:
Фронт:
Условно: при переходе между роутами мы делаем 2-4 запроса до первого рендера (профиль, права, фичи, баннеры), плюс часть из них блокирует гидратацию/рендер.
Факт: LCP целевой страницы 10-12 секунд (p75), INP 300-400 мс, отказы на этой странице растут.
Гипотеза: если убрать блокирующие запросы при переходе между роутами (перенести часть запросов после первого рендера, добавить prefetch, закешировать то, что и так редко меняется, разгрузить критический путь), то:
- LCP перед переходом и на целевой странице станет 6-8 секунд
- INP станет 200-250 мс
- отказы/отток на этой странице снизятся (в рамках статистики)
Цена: N часов разработки + N часов QA + 1-2 дня на замеры до/после.
Договоренности: не растет error rate (JS ошибки), не падает конверсия на ключевом шаге.
Бек:
Условно: генерация документов делается прямо в основном потоке запроса.
Факт: p95 latency 900-1200 мс, CPU 85-95% на пиках, очередь запросов растет, иногда ловим таймауты, пользователю "долго ждет".
Гипотеза: если добавить воркер и вынести генерацию документов туда, то основной поток разблокируется:
- p95 по основным ручкам станет 450-600 мс
- таймауты и error rate по этим ручкам снизятся
- система перестанет деградировать на пиках (очередь стабилизируется)
- пользователю перестанет "фризить" сценарий (особенно если документ не нужен прямо сейчас)
Цена: N дней разработки + нагрузочное тестирование + проверка деградаций + план отката.
Договоренности: стоимость инфраструктуры не растет неконтролируемо, нет дубликатов генерации, есть идемпотентность, SLA не ухудшается.
Шаблон, который можно копировать себе:
- Проблема: (что болит, где, у кого)
- Baseline: (какие значения метрик сейчас)
- Гипотеза: (если сделаю X, метрика Y изменится на Z)
- Target: (конкретные числа и период измерения)
- Цена: (часы/дни/ваша оценка, QA, риски, зависимости)
- Договоренности: (что не должно ухудшиться)
- План отката: (как вернуться на стабильную версию)
А потом в конце эксперимента сверяйся насколько ты был близок. Запиши вывод: что сработало, что не сработало, почему. Это формирует видение, личный опыт, и умение защищать гипотезы как минимум технические.
3
3
1
1February 19, 2026 1K 2 7
