Пример типичной спеки на простую учётную систему
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] и отложенные эффекты – тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов – учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте.

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

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

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

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

"Чтобы жизнь тебя устраивала, сначала устрой её. Иначе она устроит тебя не туда, куда тебя устраивает." — Стас Янковский

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

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

Вначале я научился писать высокоэффективный код. Это когда код качественный и пишется быстро.

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

Потом я понял, что нужно уметь формировать над командой защитный зонтик, чтоб они умели применять навыки в реальных условиях давления бизнеса. Бизнесу нужно быстро, команде нужно качественно, что означает тоже быстро, но завтра. Но бизнес это не всегда понимает. Найти баланс помогла книга "Extreme Programming Explained" 1st edition by Kent Beck.

Потом я понял, что крутой специалист может изменить все, кроме процессов. И именно безграмотно организованные процессы являются основной причиной утраты наиболее ценных специалистов, что обрело устойчивый термин "голосование ногами". И я начал изучать SDLC.

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

В принципе, я уже излагал эту историю здесь.