Иногда хочется так много сделать, но так мало получается сделать. А у него получилось. И я хорошо понимаю, какой титанический труд за этим стоит. Хочу пожелать успехов и дальнейшего развития.

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

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

Кто не хочет погружаться в работы Barry Boehm для выбора SDLC-модели разработки, тот может использовать более простой подход - Cynefin framework (см. мини-книгу в канале @nullnullday )

Постараюсь посетить:
https://www.tgoop.com/denis_beskov/165

Там все чуть сложнее. Если совсем просто объяснять, то итерация - это "метод научного тыка".

Бытовой пример. Например, нужно обесточить и заменить розетку. Видим в щитовой кучу автоматов. Какой из них выключить? Можно, конечно, определить путем логического вывода, например, отыскать схему разводки или исследовать разводку детектором скрытой проводки. А можно просто включить в розетку лампочку и поочередно перебирать все рубильники до тех пор, пока не угадаем.

Как говорил математик Polya: "If you run into a dead end in one of the areas, iterate!".

Суть итерации в том, что иногда проще сделать и изменить, чем пытаться угадать с первого раза.

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

Решение оказывается мертворожденным. Чтоб его оживить, возникает соблазн окутать его метастазами системы.

Это к вопросу о том, должен ли архитектор уметь в код. Нет смысла делать крышу, если стены кривые, а вместо прочного фундамента - палки с ... ну вы знаете, в общем.

Система отражает то, что творится в головах программистов. А значит, здоровье системы начинается отсюда. Это и есть фундамент. Согласен с Gregor Hohpe в том, что табуретка архитектора о трёх ногах: Skill, Impact, Leadership.

Лидерство. Архитектор или становится вождем и принимает на себя ответственность за судьбу проекта, или он рисует мертворожденные стрелочки с квадратиками где-то на обочине жизненного русла продукта. Еще недавно подобное явление называли "хвостизм". Наверное, поэтому первой книгой в списке от Gregor Hohpe идет книга "Clean Code". А второй - "Refactoring".

💬 "When designing a single software component, architects should focus on good coding and design practices." -- Gregor Hohpe

Знания программистов - это первое, с чего я всегда начинал работу на новых проектах. И только потом - стрелочки и квадратики. Тем более, что в Screaming Architecture эти стрелочки не так уж сильно и нужны. А от лапшы они все-равно не спасают.

Лекционный формат не работает. Одна картинка стоит тысячи слов. Поэтому важно сделать один сервис образцово-показательным. А дальше copy-paste сделает свое дело. Программисты часто прибегают к копированию. Было бы что копировать. Если копировать нечего, тогда наступает царство "Теории разбитых окон". Если копировать нечего, то оно само не появится (иначе появилось бы раньше). Значит, его должен создать архитектор. Сам, или совместно с программистами, - зависит от ситуации.

Обычно странглирование оказывается эффективней рефакторинга. Странглирование еще и выгодней по политическим причинам - новое будет хорошо контрастировать на фоне старого. Это если, разумеется, архитектор умеет в код, и умеет быть лидером.

Про полиграфы. В наше время находятся работодатели, которые считают, что вправе заставлять соискателя оправдываться перед ними в своей невиновности еще до того, как те успеют поработать на них.
https://www.youtube.com/shorts/1_pE1MaV8_A

Много раз на практике наблюдал ситуацию, когда специалист имеет правильное понимание, но не может его аргументированно донести своим коллегам. Возникает борьба за лидерство, токсичность, конфликтность. Одни только баттлы вокруг SRP чего стоят. Нередко это заканчивается агрессивно-пассивной позицией: "делай как хочешь, только меня потом не трогай".

Ключем к пониманию ситуации является слово "потом".

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

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

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

Я уже говорил, что лидерство заключается, в первую очередь, в дальности горизонта видения. Еще в Дао Де Цзин писали, что мудрый лидер управляет не запретами, а проливанием света на последствия. Вот этот горизонт видения и есть то самое, вокруг чего люди объединяются.

Именно поэтому Craig Larman говорил:
💬 “Место, где происходит реальная работа” в программировании - это код, из чего следует, что первоклассными менеджерами должны становиться лучшие разработчики, которые часто оценивают код.
- Craig Larman, https://less.works/ru/less/principles/systems-thinking.html

Хороший лидер уберегает от проблем. Потому что способен их предвидеть. Потому что знает. Что означает, что ничто другое не имеет значения.

Как говорил Л.Н.Толстой, один из самых влиятельных людей мира, единственным инструментом власти которого было слово:
💬 "Всякая истина, выраженная словами, есть сила, действие которой беспредельно".

Поэтому очень важно не только видеть правильное решение, но и видеть причинно-следственные связи, приводящие к этому решению.

Хорошим примером является DDD. Зачастую разработчики интуитивно чувствуют его полезность, но не понимают какую именно проблему он решает. Попытки "насадить" DDD могут привести к формированию оплота сопротивления. Даже у Nick Tune, известного автора по DDD, такое случалось.

В последнее время иногда слышу термин "управление накоплением знаний". Я уже говорил о том, что процесс обретения знаний сопровождается сокращением количества информации. Подобно тому, как скульптор освобождает образ, отсекая все лишнее. Коллекционировать знания не нужно, т.к. можно запутаться.

Иногда приходилось наблюдать ребят, которые начинали заниматься накопительством знаний, пока не начинали тонуть в когнитивной нагрузке. На этом их процесс развития останавливался, и они возводили стены психологической защиты вокруг того, что они успели освоить. Тот информационный хлам, который они успели бесформенно освоить, создавал у них иллюзию наличия знаний, усиленную эффектом иррационального усиления на вершине пика глупости кривой Даннинга-Крюгера. Что приводило к их высокой токсичности.

Пост на аналогичную тему:
https://www.tgoop.com/ru_arc/178

Подборка материалов для подготовки аналитика:
https://www.tgoop.com/denis_beskov/173

Список литературы по архитектуре от @davydovanton
- https://gist.github.com/davydovanton/f6b95dad1a0ec05ce6d1b0f7358d2b44

Очень интересная метафора про гибрибные модели разработки:

💬 Once upon a time, in a land steeped in metaphor, there lived an elephant. For many years, this reliable elephant served his village as the principal food gatherer and knew just what the village needed. He established paths through the jungle that always led him to the best roots, vegetables, nuts, and fruits. He knew which fruits he could reach with his trunk and which ones required some trunk shaking. His massive strength enabled him to bring back enough food for several days, so he always anticipated the requirements of the village and maintained adequate supplies. He was faithful to his task, was appreciated throughout the village, and thought his life most rewarding.

Alas, things began to change, as they often do in life and fable. The village cooks wanted different, rarer ingredients for their cooking, things the elephant had heard of but were not along his well-worn trail. He busily maintained stores of food that no one wanted but couldn’t fi nd time to make new paths for meeting new requests. The village grew impatient with the discouraged elephant, who just couldn’t keep up with the demands.

Around the same time, there was a monkey in a nearby village whose job mirrored that of the elephant. Unlike the elephant, however, the agile monkey flitted across the jungle grabbing fruit as he saw it, finding the low-hanging fruit and bringing it quickly back to the village cooks. Rather than the time-proven trails of the elephant, the monkey relied on his memory and instincts to find food and brought back only the amount needed that day. Some-times he ran off looking for increasingly exotic foods and occasionally got lost. But his speed and agility always proved equal to the tasks the village set for him, and like the elephant, he was greatly appreciated.

Unfortunately, the monkey’s life changed, too. His successful village grew larger every day. The monkey had so many requests that he was constantly on the move, trying to remember all the needs at every location. He had to make many more trips because he just didn’t have the strength to carry everything requested at the same time. The village began to get impatient with him as well, and the monkey began to doubt he could do the job.

As luck would have it, the weary monkey and the discouraged elephant met one day. The monkey, trying to move quickly with a large load, noticed how much food the elephant was carrying in the panniers on his back. The elephant was impressed with the monkey’s speed, how far he could travel, and how easily he could gather some of the food that the elephant struggled to reach. Both animals, proud of their skills, never-theless acknowledged that there were obvious advantages to the other’s abilities.

The elephant and monkey recognized the benefits of working together and decided to join forces.
The monkey would use his agility to meet the new requests to fi nd distant fruit, bringing it back to the elephant for his village. The elephant would carry suff i cient quantities of food to the monkey’s village to meet the growing needs of the population. It took them a while to work out just how to do this, but soon they had things going well for both villages. And so, they lived happily ever after, secure in their mutual trust and the appreciation of well-fed villagers.

-- "Balancing Agility and Discipline" by Barry W. Boehm, Barry Boehm, Richard Turner

Пример типичной спеки на простую учётную систему
https://drive.google.com/file/d/1HVDs7MLLniG_XmYYzGcOPKc3nfxesJuB/view

Система:

A system is an arrangement of parts or elements that together exhibit behavior or meaning that the individual constituents do not
(INCOSE Fellows, 2019)

Combination of interacting elements organized to achieve one or more stated purposes
(ISO/EC/IEEE 2015)

Множество элементов, находящихся в отношениях и связях друг с другом, которое образует определенную целостность, единство (Садовский, БРЭС)

Совокупность взаимосвязанных элементов, обособленная от среды и взаимодействующая с ней как целое
(Перегудов, Тарасенко)

Совокупность элементов, объединенных общей средой функционирования и целью функционирования
(Хомяков)

Сущность, которая в результате взаимодействия ее частей может поддерживать свое существование и функционировать как единое целое (О'Коннор, Макдермотт)


Статистика этого поста наглядно демонстрирует, насколько недооцененными со стороны специалистов являются наиболее важные и фундаментальные вещи. Без понимания того, что в нем изложено, в принципе невозможно создать успешный проект и хоть как-то укротить разбегающуюся во все стороны лапшу. Это основа основ. Понимание сути модели специалистами - это первое, с чего я всегда начинаю оздоравливать систему. И действует это понимание как волшебная пилюля. Если и существует Silver Bullet, то это оно.

Отвечал в одном чате, и, думаю, есть смысл скопировать сюда:

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

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

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

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

Во всех перечисленных четырех моделях рассматриваются совершенно различные аспекты оригинала.

В плохо смоделированных системах возникает т.н. "звездная/божественная" модель, которая служит сразу всем целям. Модель разбухает, проникает в другие модели. Осведомленность произростает лапшой через всю систему, локализация изменений испаряется, хрупкость системы возрастает, и образуется то, что называют Big Ball of Mud.

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

На практике зачастую моделирование начинается от сущностей, и тогда часто возникают вопросы типа "что мне делать, если мне нужна сущность из другого микросервиса?". Вместо того, чтоб создать модель, отражающую релевантные аспекты оригинала в нужном микросервисе (или в BC, который является границей модели), начинает использоваться агрегат из нерелевантной модели (другого микросервиса), что зачастую приводит к его обрастанию нерелевантными аспектами. Агрегат разбухает, и потом никто не может разобраться что в нем содержится и для чего. Изменение такого агрегата может вызвать катастрофу из-за высокого уровня связанности. А команда, владеющая агрегатом, вынуждена изучать его использование во всех других моделях (микросервисах), что многократно повышает когнитивную нагрузку и убивает автономность команды, что приводит к прогрессированию т.н. Проблема Брукса (бесконтрольный рост коммуникативной нагрузки).

Собственно говоря, топология команд зависит от архитектуры именно по этой причине, что называется сегодня термином Team First Architecture. Некачественное моделирование может убить весь проект. Он просто потонет в бесконтрольном разгоне сложности и коммуникативной нагрузки. Верный путь довести проект до ручки - это "звездные" модели.