# 03. Технический долг

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

- **Author:** Фёдор Чищин
- **Level:** advanced
- **Reading time:** ~25 минут чтения
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/ru/learn/software-architect-03-technical-debt

---

## 1. Главная идея

Долг полезен, когда покупает время. Долг опасен, когда команда не знает, что взяла кредит.

### Не всякий плохой код — долг

> Кредит и украденный кошелёк оба создают финансовую проблему. Но управлять ими нужно по-разному.

Technical debt появляется, когда команда сознательно выбирает более дешёвое сейчас решение, понимая будущую стоимость. Например: «Мы не делаем полноценную multi-tenant модель до первых платящих клиентов». Это долг.

А вот «мы не написали тесты, потому что забыли» или «никто не понял инварианты» — это не долг, а дефект engineering discipline. Называть всё долгом опасно: бизнес перестаёт понимать, где стратегический компромисс, а где просто плохая работа.

### Проценты важнее суммы долга

> Маленькая яма на дороге рядом с домом раздражает каждый день. Большая яма в лесу может годами никого не волновать.

Проценты по долгу — это замедление изменений. Если долг лежит в hot path разработки, он дорог даже при малом размере. Если долг в редко трогаемом скрипте миграции, он может быть терпим.

Архитектор оценивает не только «насколько некрасиво», но и «как часто мы платим за это». Поэтому debt register должен содержать impact, owner, trigger for repayment и risk.

## 2. Пример и антипример

Долг становится управляемым, когда у него есть причина и стратегия выплаты.

### Пример: временно один регион

> Магазин сначала открывает одну точку, а не строит федеральную логистику до первой продажи.

Команда запускает SaaS только в одном регионе, хотя знает, что enterprise-клиенты позже потребуют data residency. Решение записано в ADR: сейчас один регион, потому что нет клиентов с таким требованием; пересмотр при первом enterprise контракте или при 20% пользователей из ЕС.

Это разумный deliberate debt. У него есть причина, границы и триггер пересмотра.

### Антипример: «потом перепишем»

> Фраза «потом перепишем» без даты и условия — это не план, а заклинание.

Команда пишет billing без идемпотентности, потому что «пока мало пользователей». Это опасно: ошибка может сразу стоить денег и доверия. Такой долг неразумен, потому что риск непропорционален экономии.

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

#### Самопроверка

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

Следующий модуль: [Cognitive load](./software-architect-04-cognitive-load).