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

а для этого существуют тимлиды и разного рода менеджеры (ресурсные например)

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

Ну а вот этот кейс, когда архитектор имеет доступ к коду.
Как это может выглядеть?

Арх открыл репозиторий -> Арх нашел "неархитектурное" -> Арх доказал заказчику что нужно выделить ресурсы на исправления -> Арх создал issue или переложил на соответствующую команду?...

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

Арх. (тех.) накапливается не "выбрали" , а "изменилось". Например, раньше не было стандарта на СУБД, и все писали кто на чем хотел. А потом в компании он появился. И в командах образуется тех. долг

ну примерно так. выделение ресурсов это конечно совершенно отдельный вопрос, но в целом да.

» А потом в компании он появился. И в командах образуется тех. долг
Если бы debt так работал напрямую, без контрактов  - то мы бы давно размыли и цифру, и экономику.
Хорошо, что debt, всё-таки, не производная от "что-то где-то появилось"

Чего?

Я вас не понял ))

Тех. долг появляется по двум причинам:
- либо изменились условия и старые решения не актуальны
- либо команда сознательно допускает его появления (это не хорошо и не плохо, это факт, часто вызванный больше внешними для команды факторами, чем внутренним желанием команды)

"И в командах образуется тех. долг"
Я к этому, как-будто долг сам образуется, просто вот сам.
Тут можно проще сказать: представьте физическую аналогию этого процесса

Евгений, моя мысль следующая была в примере с СУБД. Команда в 2018г имела права выбрать mysql и выбрала. В 2020 пришла установка, что все проекты компании переходят на oracle. И команды появился тех долг - переход с mysql на oracle

Но нет, не появился "тех долг".
cruft и debt про разное

https://martinfowler.com/bliki/TechnicalDebt.html

👍

Евгений, значит мы не совпадаем в терминологии.

Если кратко напишите разницу между cruft и debt по Фаулеру - буду благодарен.

"Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn't sustainable in the longer term, but yields a short term benefit, such as making a release. "
То есть, это прямо "мы выбрали залезть в долг", т.е. сделать short win в ущерб lon term

Поясню, что я "думаю вслух", показывая трактовки https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

попахивает книгой про scrum

Ну то есть мой второй пункт. А чем плох трактовка, что и внешние обстоятельства изменились для команды?