Russian Association of Software Architects
Открыть в Telegram
Канал самоуправляется коллегией: @sergey486 и @emacsway . Бот для вступления в авторский коллектив: @ru_arc_bot Группы: @ru_arc_chat @rasa_business @archicases Рекламу не размещаем.
Больше
Сеть:4 348
Подписчики
+124 часа
+17 дней
Нет данных30 дней
Загружаем данные
Похожие каналы
Облако тегов
Входящие и исходящие упоминания
---
---
---
---
---
---
Привлечение подписчиков
октябрь '26окт. '26
октябрь '26
+14
в 0 каналах
сентябрь '26
+37
в 2 каналах
Get PRO
август '26
+34
в 0 каналах
Get PRO
июль '26
+35
в 0 каналах
Get PRO
июнь '26
+25
в 1 каналах
Get PRO
май '26
+30
в 0 каналах
Get PRO
апрель '26
+32
в 0 каналах
Get PRO
март '26
+50
в 1 каналах
Get PRO
февраль '26
+34
в 0 каналах
Get PRO
январь '26
+50
в 2 каналах
Get PRO
декабрь '25
+45
в 1 каналах
Get PRO
ноябрь '25
+77
в 1 каналах
Get PRO
октябрь '25
+52
в 1 каналах
Get PRO
сентябрь '25
+65
в 1 каналах
Get PRO
август '25
+139
в 2 каналах
Get PRO
июль '25
+92
в 1 каналах
Get PRO
июнь '25
+36
в 1 каналах
Get PRO
май '25
+59
в 1 каналах
Get PRO
апрель '25
+52
в 0 каналах
Get PRO
март '25
+100
в 0 каналах
Get PRO
февраль '25
+75
в 1 каналах
Get PRO
январь '25
+63
в 0 каналах
Get PRO
декабрь '24
+98
в 3 каналах
Get PRO
ноябрь '24
+110
в 1 каналах
Get PRO
октябрь '24
+176
в 1 каналах
Get PRO
сентябрь '24
+103
в 0 каналах
Get PRO
август '24
+113
в 3 каналах
Get PRO
июль '24
+79
в 2 каналах
Get PRO
июнь '24
+89
в 1 каналах
Get PRO
май '24
+133
в 3 каналах
Get PRO
апрель '24
+74
в 0 каналах
Get PRO
март '24
+80
в 0 каналах
Get PRO
февраль '24
+113
в 3 каналах
Get PRO
январь '24
+177
в 3 каналах
Get PRO
декабрь '23
+234
в 4 каналах
Get PRO
ноябрь '23
+126
в 5 каналах
Get PRO
октябрь '23
+182
в 3 каналах
Get PRO
сентябрь '23
+86
в 0 каналах
Get PRO
август '23
+83
в 0 каналах
Get PRO
июль '23
+86
в 0 каналах
Get PRO
июнь '23
+44
в 0 каналах
Get PRO
май '23
+105
в 0 каналах
Get PRO
апрель '23
+75
в 0 каналах
Get PRO
март '23
+60
в 0 каналах
Get PRO
февраль '23
+127
в 0 каналах
Get PRO
январь '23
+76
в 0 каналах
Get PRO
декабрь '22
+72
в 0 каналах
Get PRO
ноябрь '22
+149
в 0 каналах
Get PRO
октябрь '22
+213
в 0 каналах
Get PRO
сентябрь '22
+255
в 0 каналах
Get PRO
август '22
+185
в 0 каналах
Get PRO
июль '22
+1 186
в 0 каналах
| Дата | Привлечение подписчиков | Упоминания | Каналы | |
| 18 октября | +2 | |||
| 17 октября | +2 | |||
| 16 октября | +2 | |||
| 15 октября | 0 | |||
| 14 октября | 0 | |||
| 13 октября | 0 | |||
| 12 октября | 0 | |||
| 11 октября | +1 | |||
| 10 октября | +2 | |||
| 09 октября | 0 | |||
| 08 октября | 0 | |||
| 07 октября | 0 | |||
| 06 октября | +1 | |||
| 05 октября | +1 | |||
| 04 октября | 0 | |||
| 03 октября | +1 | |||
| 02 октября | +1 | |||
| 01 октября | +1 |
Посты канала
Новый кейс в архитектурных этюдах
Про неполноту данных, при этом эти данные еще и относятся к специальной категории.
https://t.me/archicases/10216/10217
| 2 | Новый кейс в архитектурных этюдах:
https://t.me/c/archicases/10216 | 1 |
| 3 | Переосмысление архитектурной функции 2/2
Продолжение (начало).
Теперь о составе функции. Долгое время часть решений считалась архитектурными просто потому, что их реализация была дорогой и требовала большого объема ручной работы. Когда цикл пересмотра решения сокращается, часть решений можно принимать ближе к реализации и корректировать по мере появления новой информации. Руководителю важно отличать решения, которые можно недорого пересмотреть, от решений, последствия которых переживут конкретную реализацию. С этой темой я выступал на JVM Day от Т-Банка, может скоро появится запись, но суть в том, что архитекторной функции теперь жизненно необходимо сосредоточиться на нетиповых решениях, а не забивать время обсуждениями потока типовых решений, которые могут быть приняты ближе к разработке.
И главная мысль, которая проскальзывала через большинство разговоров, – стоимость изменения работающей системы не сводится к стоимости программирования (а она сейчас не так очевидна в моменте, потому что ФОТ всегда был основной статьей расходов в разработке). Миграция накопленных данных, изменение обязательств перед внешними потребителями, устранение последствий потери доверия – это не то же самое, что переписать модуль. AI может помогать в такой работе, но он не отменяет ни связанности систем, ни рисков миграции, ни сложности развертывания, ни системных эффектов изменений. Если посмотреть на живые SDLC-процессы, становится очевидно, что скорость производства кода сама по себе не всегда делает изменение продукта дешевле. Без стабильной поставки и гарантий выполнения атрибутов качества стоимость изменений может даже вырасти, – компания теряет клиентов, не выполняет обязательства, тратит больше на инфраструктуру. Быстро получить реализацию еще не значит быстро получить надежный результат.
Вывод в целом очевиден. Не всем нужен архитектор, но, похоже, всем нужна архитектурная функция в том или ином виде. Ее могут составлять архитектор, команда, автоматизированные механизмы, а чаще – их сочетание. Так было и раньше, теперь этого проще добиться и вопрос уже не «как это сделать?», а «почему еще не сделано?». Главное, чтобы в изменившихся условиях функция с нужной скоростью обеспечивала должное качество решений и проверку их последствий.
Если в вашей компании архитектурная функция переживает кризис самоопределения, давайте обсудим, разговор ни к чему не обязывает. Пишите в личку @sergey486, договоримся о встрече. Вам – второе мнение, мне – более глубокое понимание ситуации 🤝 | 693 |
| 4 | Переосмысление архитектурной функции 1/2
Последние две недели было много встреч и мероприятий, много разговоров о том, в каком состоянии сейчас архитектурная функция и где место архитекторов. Говорил и неформально со старыми знакомыми и на рабочих встречах с первыми лицами организаций. Свел заметки и наблюдения и, наверное, главная мысль – сегодня архитектурной функции как никогда ранее важно понимать не только саму себя, но и то, как ее воспринимает система, в которую она встроена.
До появления AI архитекторы спорили о ценности своей функции в основном между собой. Теперь вопрос ставится управленчески, а именно – за какую работу компания готова платить архитектурной функции (JTBD, получается)? Компания может меньше нуждаться в отдельном архитектурном подразделении и при этом сильнее зависеть от качества архитектурных решений (такой вот парадокс). Для бизнеса это значит перераспределение ценности. Производство артефактов теряет в цене, при этом решения, последствия которых выходят за пределы кода, свою ценность сохраняют. AI уже помогает разбираться в существующем коде, находить пробелы в архитектурных решениях, модернизировать системы и готовить архитектурные тесты. Привычные практики планомерно пересматриваются.
Отсюда ключевое управленческое противоречие: если результат архитектурной функции – это преимущественно документы, диаграммы и рекомендации, насколько оправдана ее прежняя стоимость? Сама по себе сложность системы больше не обосновывает отдельный штат экспертов. Функции придется явно показывать, какие риски она снижает, какие изменения ускоряет и какие дорогостоящие ошибки предотвращает.
Оценивать любую функцию по приносимой пользе – нормальная управленческая практика. Проблема в том, что архитектурная функция долго находилась как бы сбоку. Она снижала риски, повышала надежность, прорабатывала решения на соответствие требованиям регуляторов, но редко действовала проактивно и чаще работала в режиме исполнения запросов. Сейчас от нее ждут полноценной интеграции в корпоративную систему, начиная с инвестиционных комитетов (или их аналогов, где принимаются финансовые решения). Ну как ждут. Управленцу проще уволить, если он не понимает, за что платит, так что это во многом задача руководителей функций сделать пользу от функции явной и понятной. Она действительно явная и понятная, то есть это не то, что нужно придумать пользу от своей работы, другое дело, – она часто не видима там, где видимы затраты.
Продолжение | 610 |
| 5 | 🎤 Выложил запись доклада "Сжатие приводит к истине? Как LLM выбирает, во что верить". Это рассказ про исследование, про которое уже писал, плюс все что накопал с тех пор
И сразу мега крутая новость: вчера мою статью "Truth as a Compression Artifact in Language Model Training", на которой построен доклад, приняли в основной трек NeurIPS 2026!
Моя первая серьезная научная статья - и сразу на одну из главных конференций по ИИ в мире!!!1 🎉🎉🎉
Насколько я смог найти, это вообще первый случай, когда в основной трек взяли работу независимого автора-одиночки из России
Началось все с простого вопроса. Почему модели из разных стран одинаково не верят в астрологию, гомеопатию и в то, что на одной китайской площади ничего не произошло? В обучающих данных миллионы сайтов с гороскопами и весь китайский интернет. Чтобы разобраться, пришлось вступить на скользкую дорожку борца с мифами и лженаукой
Главная мысль - обучение вымывает из данных непредсказуемость. Из научных данных можно последовательно делать предсказуемые выводы, поэтому наука хорошо сжимается. Астрология нет: по одной натальной карте разные астрологи выдают абсолютно разные прогнозы. Чтобы это проверить, обучил с нуля 300+ LLM-моделей разной архитектуры от 3.5M до 3B параметров. Никаких инициализаций открытыми весами, чистый рандом. Начал на своем маке, а закончил на кластере из восьми H100. Было дорого
В докладе:
- 1:14 - миф про 10% мозга (который так любят бизнес-коучи)
- 3:20 - Кеплер и эпициклы
- 4:47 - плоскоземельщик на ток-шоу
- 6:34 - из лжи следует что угодно, или как Рассел доказал, что он Папа Римский
- 11:12 - случайные ошибки модель вымывает, даже когда правильных ответов всего 10%
- 12:33 - одно согласованное ложное правило - и предпочтение правды пропадает
- 13:29 - с несколькими ложными правилами модель вдруг неожиданно начала предпочитать сложную ложь обычной математике. Потом рецензенты нашли ошибку в подсчетах
- 15:05 - разбавил математику текстами из FineWeb так, что ее осталось 8%
- 16:05 - случайно меняем географию в Википедии, так что в истории Франции появляется Уссурийск
- 17:19 - что нашли рецензенты NeurIPS
- 18:26 - главный вывод
В посте про расцензуренный DeepSeek я писал, что алайнмент полностью снялся правкой 0,06% весов, а во что модель верит по-настоящему, решает претрейн. Когда китайская модель в чате уходит от ответа - это работа алайнмента, картина мира у нее может быть совсем другой. А вот для претрейна согласованная дезинформация неотличима от истины. Спасает то, что настоящие фейки редко бывают согласованными до конца
Статья на arXiv | Код и данные на GitHub | Презентация из доклада
P.S. Первое, что мне написали рецензенты: "парень, у тебя какая-то ерунда в данных". Они были правы - и теперь это статья на NeurIPS 😄
P.P.S. Число подписчиков моего канала уже почти 5000 человек (или агентов, тут уж не знаю). Мне очень приятно, спасибо 🙏 | 17 |
| 6 | The Specification Paradox: Rethinking Requirements Engineering in the Age of AI
Простая для восприятия статья поразмышлять о требованиях, но в которой есть несколько интересных моментов.
Думать все равно приходится:
The distribution of human effort also changes. Using eye tracking and interaction monitoring, [13] found that developers working with LLM-generated code devote substantial cognitive effort to understanding, inspecting, validating, and correcting generated solutions. Automatic generation therefore does not eliminate human work; it shifts part of that work from implementation toward supervision and evaluation.
Это то, с чем я вчера столкнулся, когда попытался быстро сделать скрипт для работы с метаданными репозитория, – 70GB памяти на обработку репозитория из 1000 коммитов, при этом функционально все отработало корректно. Проблема была в хранении всех данных всех диффов в памяти с последующим их копированием в последующие модули, при этом сами данные не нужны, нужны высчитанные на их основе значения. Важно то, что когда я спросил агента зачем ему столько памяти, он обоснованно ответил (но сразу стало понятно, что так делать не надо), когда же попросил его исправить, он исправил только в одном месте. В итоге понадобилось ему подробно объяснить алгоритм работы, буквально дизайн и тогда он все исправил, но при этом пришлось походить по коду, чтобы объяснить ему в терминах кода что и где менять, а была надежда на то, что в год залезать не придется.
В выводах то, вокруг чего сейчас много холиваров:
Generative artificial intelligence is transforming Software Engineering by automating the generation of code and other software artifacts. Yet it does not eliminate the essential complexity described by [3]; rather, it redistributes engineering effort from implementation toward domain understanding, specification, validation, and software evolution.
This shift underlies the Specification Paradox: the more capable AI systems become at generating software, the greater the dependence on high-quality
human-produced specifications. As specifications increasingly guide automated generation, their quality directly affects the reliability and alignment of generated artifacts. Rather than diminishing RE, AI may therefore strengthen its strategic role.
Таких ситуаций было значительно больше – пишешь требование, но агент понимает его по-своему, откатываешь изменения, исправляешь требования – он снова понимает немного не так, ограничиваешь, добавляешь деталей и так, пока не получишь нужный результат. У агента при этом есть память, но чтобы она работала на развитие навыка, нужно не откатывать и писать заново, а использовать roll-forward, – добиваться нужного результата через Change Request’ы, что безумно утомительно. Однако, в большей степени зависит от механизма накопления знаний, но цикл в любом случае должен замкнуться каким-то подкреплением.
Если выйти за пределы статьи, то для себя сделал чуть более широкий вывод, что узкое место – не просто качество изначальных требований, но и стоимость превращения обнаруженной ошибки в устойчивое ограничение для следующих итераций. | 1 314 |
| 7 | Простая для восприятия статья поразмышлять о требованиях, но в которой есть несколько интересных моментов.
The distribution of human effort also changes. Using eye tracking and interaction monitoring, [13] found that developers working with LLM-generated code devote substantial cognitive effort to understanding, inspecting, validating, and correcting generated solutions. Automatic generation therefore does not eliminate human work; it shifts part of that work from implementation toward supervision and evaluation.
Думать все равно приходится:
Generative artificial intelligence is transforming Software Engineering by automating the generation of code and other software artifacts. Yet it does not eliminate the essential complexity described by [3]; rather, it redistributes engineering effort from implementation toward domain understanding, specification, validation, and software evolution.
This shift underlies the Specification Paradox: the more capable AI systems become at generating software, the greater the dependence on high-quality
human-produced specifications. As specifications increasingly guide automated generation, their quality directly affects the reliability and alignment of generated artifacts. Rather than diminishing RE, AI may therefore strengthen its strategic role. | 1 |
| 8 | Дублирование логики при работе с агенами
Развивая мысль модульности и финансовой оценки изменений при применении агентов стоит затронуть тему дублирования логики.
Протечка абстракций может содержаться не только в существующей реализации, но и в самой постановке. Причем в постановке она может содержаться неявно, автор требования может этого не предполагать, но агент примет собственное решение.
Выглядит так, что этому в меньшей степени могут быть подтвержены OpenSource проекты, так как в нихчастой единственный репозиторий. В организациях же репозитории раздельны как физически, так и организационно.
Таким образом, при постановке задачи без явного описания модели предметной области и четко и явно прописанных границ, агент может быть склонен решать задачу используя свое представление о модели. И он решит задачу, при этом напишет собственную логику вместо использования внешнего API для этой логики, так как не знает о наличии этой логики в соседнем репозитории.
Это, в свою очередь:
1. Увеличивает общий объем кода и общий объем изменений за счет дублирования функциональности в различных частях организации
2. Приводит к необходимости координации изменений в будущем, если различные реализации одной и той же логики участвуют в одном и том же глобальном бизнес-инварианте (используются для расчета налоговой базы, например)
При этом важно отметить, что сама по себе слабая фиксация границ не обязательно ведет к появлению дублирования, однако при этом значительно повышает вероятность роста количества токенов за счет того, что оставляет более широкие границы при анализе вариантов и, как следствие, повышение объема рассуждений. То есть единицей проблемы становится область видимости агента относительно области действия инварианта.
Если рассмотреть это через призму одной из задач архитектуры, – «снижение стоимости последующих изменений», то ключевой вывод может звучать так:
Неясная граница ответственности снижает вероятность обнаружить существующего владельца инварианта. Агент может удешевить текущую задачу локальной реализацией, одновременно повысив ожидаемую стоимость будущих изменений и риск расхождения поведения. | 1 118 |
| 9 |  Identifying and Quantifying Architectural Debt
https://dl.acm.org/doi/epdf/10.1145/2884781.2884822
AI раскрывает новые возможности. Если раньше читаешь и понимаешь - дааа, но лень, то теперь действительно многое можно достаточно быстро опробовать.
Я раньше использовал адаптированный под себя code-maat, дописанный-переписанный, но Clojure я до этого не знал, так что приходилось дописывать по-немногу и делать интеграцию через файлы, а теперь открылись просто новые грани.
В этой статье арх долг на границе дизайна и архитектуры:
ArchDebt=⟨FileSetSequence, DebtModel⟩, где
FileSetSequence — это последовательность связанных групп файлов в разных релизах
DebtModel описывает, как менялись затраты на исправление ошибок в этих группах
В статье поиск происходит в несколько стадий:
1. Crawling - отбор областей поиска, - файлы, которые хотя бы раз менялись ради исправления ошибки с первого релиза по текущий, после чего отбирают группы файлов и их зависимостей, – у которых ведущий файл находится в этом пространстве ошибок.
2. Indexing - из истории исправлений строят матрицу History Coupling Probability (HCP). Ячейки HCP[A,B] показывают условную вероятность изменения B, если изменился A. В каждой группе есть опорный файл, остальные файлы могут добавляться или исчезать от релиза к релизу
3. Modeling. В исследовании кандидат должен встречаться как минимум в половине релизов и иметь бОльшие затраты к последнему наблюдаемому релизу, чем к первому. Затраты приближают числом измененных строк кода в исправлениях ошибок (bug-fixing churn) по файлам группы. Тут чуть ли не самое интересное – раньше можно было бы сказать, – да ладно, в строках кода считать моветон, а если это агент, то это токены == деньги.
4. Ranking - найденные долги упорядочивают по связанным с ними накопленным затратам
Пример в статье с Cassandra показал, что «ADFileSet calculated using anchor ColumnParent in Cassandra. Each member file structurally depends on the anchor file, and when the anchor file changes, the member files change as well with probabilities from 41% to 100%.». Расценивается как сигнал для проверки.
Долг оценивается через bug-fixing churn, то есть объем изменений при исправлении ошибок.
Неявно можно предположить, что высокий bug-fixing churn может потреблять больше токенов (когда мог бы потреблять меньше). То есть понятно, что потребление зависит от самой задачи, (вход+выход+иные задачи), но при прочих равных, меньшая связанность может потреблять меньше.
Усилить можно, если выйти за пределы репозитория, тогда и без токенов координационная нагрузка подсветит дополнительные расходы, для этого нужно построить связку через багтрекер (она должна быть), но часто связей между зависимыми задачами разных команд нет, это усложняет задачу.
Написал скрипт по статье, отладил, проверял три гипотезы:
H1. При одинаковом объеме правок багфикс в бакете архитектурного долга требует больше токенов контекста, чем изолированный фикс
H2. По числу изменённых строк нельзя понять, сколько токенов понадобится модели (в большом бакете долга токенов больше, чем следует из объема правок)
H3. Контекст из связанных файлов долга заметно больше контекста только из измененных файлов (соответственно чем больше меняется, тем выше скорость роста числа токенов, так как увеличивает число читаемых файлов с некоторой вероятностью). Очевидная гипотеза, но интересно посмотреть.
Проверка через tiktoken, репозиторий: https://github.com/temporalio/sdk-java
Результат на скрине.
Общий вывод
Нарушение модульности дороже изолированной правки и в текущем фиксе, и в каждом следующем.
Последующие фиксы платят тот же контекст снова.
В первой четверти истории типичному такому исправлению хватает примерно 9 300 токенов контекста. Со второй четверти типичный контекст поднимается до 30 000 и дальше держится около 34–35 тысяч.
Лишние токены по четвертям: 3,0 млн, 5,2 млн, 4,5 млн, 4,7 млн.
Исходник стыдно выкладывать и он съедает 70gb памяти на таком небольшом проекте, так что в другой раз. | 1 093 |
| 10 | На что вы опираетесь при выработке архитектурных решений? (возможен множественный выбор) | 3 088 |
| 11 | Проверим как у нас дела с обучением =) Сколько различных платных обучений вы прошли в этом году? | 2 488 |
| 12 | Новый кейс в «Архитектурных этюдах»
Как решаете задачи валидации, когда смешиваются в одной задаче и размытые формулировки и алгоритмически проверяемые (обязательно) факты?
https://t.me/archicases/10055/10056 | 1 840 |
| 13 | Запись вебинара «Определение объектов и границ объектов NFR»
Youtube: https://www.youtube.com/watch?v=7sLMNBNCMi8
VK: https://vkvideo.ru/video-184472537_456239215 | 1 410 |
| 14 | Старт через 5 минут. | 408 |
| 15 |  NFR – это требование к чему именно?
Наверняка у всех вас в том или ином виде описаны атрибуты качества, такие как безопасность, производительность, масштабируемость. На первый взгляд все в порядке: они указаны и даже заданы количественно или качественно. Однако при детальном рассмотрении часто выясняется, что совершенно непонятно, к какому объекту относится требование.
Требование производительности – к чему конкретно? К продукту? К отдельному модулю? К сервису? К данным? К конкретному пользовательскому сценарию?
К каким проблемам это может привести?
▪️Компания берет на себя обязательства, которые невозможно проверить и защитить перед клиентом или регулятором: не зафиксировано, к какому именно объекту относятся эти обязательства
▪️Архитектурный артефакт невозможно однозначно спроектировать и протестировать, если NFR сформулированы без привязки к нему
▪️Требования нельзя проверить на полноту и согласованность между командами, поскольку отсутствует воспроизводимая практика определения объектов и границ NFR
Что разберем на вебинаре?
Одна из обязательных частей сценария атрибуты качества – объект, к которому относится требование.
На вебинаре обсудим два вопроса:
▪️Какими бывают объекты NFR?
▪️Как определить границы этих объектов?
Вебинар проведет Сергей Баранов.
🗓 8 сентября, 17:00 МСК
🔗 Подключение: https://scrumtrek.ktalk.ru/sccu2uneqagt
Регистрация не требуется – добавляйте событие в календарь, чтобы не забыть 🙂 | 1 906 |
| 16 | Поговорим о знании
Существует модель описания знания, включающая в себя три основных компонента:
- декларативное знание (что?)
- процедурное знание (как?)
- условное знание (когда и почему?)
Декларативное знание - это факты и утверждения, процедурное - правила действий.
Декларативное - предпосылка для процедурного. При этом в зависимости от обретаемого знания конкретные типы могут быть разного объема, где-то больше декларативного (теоретическая наука), где-то процедурного (езда на велосипеде).
При этом знание неотделимо от контекста и деятельности, в которой оно применяется. Подумайте о кешировании и про:
- разработку самого компонента кэша (разработчик)
- выбор класса и конкретной реализации (архитектор)
- настройка и мониторинг (SRE)
Таким образом, часть знания не существует в голове отдельно от практики, в которой она проявляется.
Помимо этого, в знании есть условные понятия, качественно меняющие понимание всей области. Вспомним снова про кеширование, с точки зрения архитектуры примером будет переход от «настроить идеально инструмент кеширования» к «пойти на компромисс между целостностью и скоростью».
Исходя из вышесказанного, декларативное знание предшествует процедурному, однако затем они развиваются в процессе обучения, но не обязательно синхронно.
Согласно модели Дрейфуса (на является универсальной, но применяется в образовании), на ранней стадии доминирует декларативное знание в виде явных, контекстно-независимых фактов, на поздних - все более интуитивным. Это, в частности объясняет, почему нельзя научиться проектированию архитектуры за короткое время, - принятие решений почти всегда контекстно-зависимое.
Универсальная модель обучения, таким образом:
- декларативные знания - обучение, чтение, наблюдение
- процедурные - повторяемая практика
- условный - накопление опыта в разных ситуациях
Важно отметить, что механизмы получения знания - не взаимозаменяемы.
Если вы идете на конференцию, например, ArchDays, - вы получаете декларативное знание, отберите для себя выступления, которые могут быть вам полезны, заранее подумайте, как сможете применить и после выступления спрашивайте спикеров именно о том, как применить, какие действия выполнять, обменяйтесь контактами, спрашивайте по мере продвижения, либо исследуйте более глубоко тему самостоятельно. Так вы получите максимальный эффект.
В организационном контексте подумайте следующем:
- достаточно ли у сотрудников декларативного знания, чтобы качественно выполнять процедуры (процессы)
- достаточно ли у сотрудников декларативного знания, чтобы реализовать в коде требуемые процедуры (фичи)
- существуют ли процедуры, развивающие то, что декларируется (мы инновационны.. но есть ли процедуры это развивающие, обучающие?)
- мы - гибкие, но заложены ли циклы обратной связи с последующими изменениями на основе этих циклов?
- ….
Для архитектора:
- декларативное - курсы, книги, доклады, документация
- процедурное - реальное проектирование систем
- условное - разбор компромиссов, работа с разными контекстами | 1 737 |
| 17 | Domain-Driven Design matters more when AI writes your code
via Learn Building Modern Go applications | 1 745 |
| 18 | В Архитектурных Этюдах новый кейс: https://t.me/archicases/9786/9787 | 2 573 |
| 19 |  Вот так Notebooklm сжал теорию первого дня корп курса по Event Storming, очень хорошо сжал, я бы сказал. Никакой лишней информации нет, так что можно выложить :) | 1 759 |
| 20 | Нет текста... | 0 |
