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

То, о чем написано в статье, сначала упаковали в Predictive coding hypothesis (PC) https://en.wikipedia.org/wiki/Predictive_coding, и в прошлом десятилетии достаточно крепко обосновали в теорию различными сканированиями мозга.

В теории PC работает на всех уровнях мышления. Распознавание кнопочек в интерфейсе или котиков в инстаграме можно отнести к "нижним" уровням мышления. Вопрос, что с этой почти общепринято доказанной теорией (осталось пару претензий от философов) делать для "верхних" уровней мышления и в коммуникации для соц/орг взаимодействиях.

вот так распознают котиков

Прошу прощения за флуд!

друзья а на кого рассчитан канал об архитектуре?
т е кто у него целевая аудитория? Архитекторы или все желающие углубить свои познания?

Полагаю, что на всех заинтересованных.

а вы с какой целью интересуетесь?)

На нас рассчитан.

Коллеги,  есть ли те кто проектировал решения для автоматизации Архивного дела. Вопрос такой:  Электронная опись и РКК электронного каталога архива как связаны?  Или это вообще об одном?

Мозг взрывается от нормативки и количества неоднозначных трактовок в ней

Вы отрасль на всякий случай уточните, банки это одно, госы это другое (причём разные по разному), да и страну тоже 😀

Вопрос снят,  разобралась

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

По вашему опыту,
1. Кто и когда выявляет техн долг?
2. Каким образом и в каком формате фиксируется техн долг?

Могу посоветовать стандарт ISO 15288 и посмотреть в рамка каких процессов затрагивается вопрос уточнения архитектуры.
Знаю, что в большинстве случаев не все положения стандарта применяются, но для начала может пригодится

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

В моем случае, речь идет про банк.
Но, я не могу себе представить, чтобы тестировщик на этапе тестирования фичи, мог выдать заключение (завести баг) на то, что разработчик сделал что-либо "неархитектурно". Чаще всего тестер заводит баги на более приземленные вещи.

Я предполагал,
что для выявления техн долга необходимо ревью архитектором. Т.е. архитектор залазит в репозиторий и смотрит, сходится ли описанное им арх решение (текст) с фактической реализацией (код)

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

Примеры техн долга о котором я говорю:
- выбрана нецелевая технология
- выбран нецелевой источник данных
- выбран нецелевой api

Ну, api же нужен не сам по себе, а чтобы им кто-то пользовался. И это тоже можно проверить.

- выбран нецелевой разработчик, который занимается фигнёй?