Software Architect · Модуль 03
Технический долг — не синоним плохого кода. Это компромисс, который должен быть осознан, записан и когда-то выплачен.
Debt quadrant · interest · repayment strategy
Долг полезен, когда покупает время. Долг опасен, когда команда не знает, что взяла кредит.
Не всякий плохой код — долг
Кредит и украденный кошелёк оба создают финансовую проблему. Но управлять ими нужно по-разному.
Technical debt появляется, когда команда сознательно выбирает более дешёвое сейчас решение, понимая будущую стоимость. Например: «Мы не делаем полноценную multi-tenant модель до первых платящих клиентов». Это долг.
А вот «мы не написали тесты, потому что забыли» или «никто не понял инварианты» — это не долг, а дефект engineering discipline. Называть всё долгом опасно: бизнес перестаёт понимать, где стратегический компромисс, а где просто плохая работа.
Проценты важнее суммы долга
Маленькая яма на дороге рядом с домом раздражает каждый день. Большая яма в лесу может годами никого не волновать.
Проценты по долгу — это замедление изменений. Если долг лежит в hot path разработки, он дорог даже при малом размере. Если долг в редко трогаемом скрипте миграции, он может быть терпим.
Архитектор оценивает не только «насколько некрасиво», но и «как часто мы платим за это». Поэтому debt register должен содержать impact, owner, trigger for repayment и risk.
Долг становится управляемым, когда у него есть причина и стратегия выплаты.
Пример: временно один регион
Магазин сначала открывает одну точку, а не строит федеральную логистику до первой продажи.
Команда запускает SaaS только в одном регионе, хотя знает, что enterprise-клиенты позже потребуют data residency. Решение записано в ADR: сейчас один регион, потому что нет клиентов с таким требованием; пересмотр при первом enterprise контракте или при 20% пользователей из ЕС.
Это разумный deliberate debt. У него есть причина, границы и триггер пересмотра.
Антипример: «потом перепишем»
Фраза «потом перепишем» без даты и условия — это не план, а заклинание.
Команда пишет billing без идемпотентности, потому что «пока мало пользователей». Это опасно: ошибка может сразу стоить денег и доверия. Такой долг неразумен, потому что риск непропорционален экономии.
Не весь долг одинаков. Долг в платежах, безопасности, данных и юридически значимых действиях требует гораздо более жёсткого обоснования.
- Почему этот долг взяли? - Кто владеет его выплатой? - Какой сигнал заставит нас вернуться? - Какие пользователи пострадают, если долг выстрелит?