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

💬 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. Некачественное моделирование может убить весь проект. Он просто потонет в бесконтрольном разгоне сложности и коммуникативной нагрузки. Верный путь довести проект до ручки - это "звездные" модели.

О лидерстве на удалёнке:
https://www.theseus.fi/bitstream/handle/10024/794439/Abbasi_Kalim.pdf

Вот таким должен быть архитектор. Я уже говорил ранее, что архитектор выполняет хищнические функции. И подобно этому орлу, он так же гордо должен расправляться с legacy и с несоответствующими решениями.

Узнал, что Taskjuggler есть web-based UI:
https://www.project-open.com/en/integration-taskjuggler

Автор книги в представлении не нуждается:
https://news.1rj.ru/str/nikitapinchuk/309

Именно. На всякий случай краткая борьба с мифами - Dr Cookie and Mr Token - Web Session Implementations and How to Live with Them (https://www.dais.unive.it/~calzavara/papers/itasec18.pdf)

Очень интересное обсуждение получилось в чате @ru_arc_chat на тему организации аутентификации в распределенной среде с использованием IAM и BFF/API-Gateway.

"Исследование компании / процесса / продукта …", Сергей Баранов

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

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

Основная специализация ребят: MSA, DDD, CQRS/ES, Clean Architecture, IoT, распределенные системы, системная архитектура, управление SDLC процессами разработки, антикризисное управление. Есть немного AI/ML.

Принципы, которые объединяют участников группы: взаимовыручка, грамотность, профессиональная репутация и уменье.

У группы есть тг-бот @krew_solutions_bot , через который участникам группы можно напрямую написать запрос на услуги Consulting, Enabling, Audit, Outstuff, Outsource, Part-time.

Это не сервер трудоустройства, поэтому, пожалуйста, не нужно никого хантить на Full-time.

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

https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html - прекрасная статья чтобы помочь определиться со статус-кодом "как мы обычно делаем".

по-прежнему ищу статьи про "всегда 200".

💬 Одной из проблем при найме разработчиков является заблуждение о небольшом разбросе в их квалификации – ошибочное мнение, будто программисты не слишком отличаются друг от друга (с точки зрения производительности, качества кода и т. д.). Но исследования показывают, что верхний квартиль по уровню квалификации способен работать примерно вчетверо быстрее, чем нижний [Prechelt00]. Довольно большая разница, согласитесь. Кроме того, модель COCOMO, основанная на многолетних масштабных исследованиях, показывает, что уровень квалификации группы разработчиков – наиболее важный из всех факторов, влияющих на ее производительность [Boehm00]. Наконец, очень слабые программисты в среднем создают код худшего качества (с плохим дизайном) и с бо‌льшим количеством дефектов, что дополнительно тормозит всю систему.

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

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

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

-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева

Петли положительной или отрицательной обратной связи[9] и отложенные эффекты – тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов – учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте.

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

Попробуйте… увидеть в системе петли положительной обратной связи.

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

-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева