Две статьи о том, что проблема гонки сообщений в шине может решаться на уровне бизнес-логики. Одна из них - от Vaughn Vernon. Он даже видит в этом превосходство DDD.

1. "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts
2. "Nobody Needs Reliable Messaging" by Marc de Graauw

#DDD #Microservices #DistributedSystems

⚡️Перечень ключевых органов и организаций, которым необходимо оценить уровень защищённости своих ИС

Официально опубликовано распоряжение Правительства Российской Федерации от 22.06.2022 № 1661-р, утвердившее Перечень ключевых органов (организаций), которым необходимо осуществить мероприятия по оценке уровня защищенности своих информационных систем с привлечением организаций, имеющих соответствующие лицензии ФСБ России и ФСТЭК России.

Более подробно о зонах ответственности по исполнению Указа Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации» можно узнать здесь.

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

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

Достоверно известно, что эта проблема ведет к падению velocity со скоростью, близкой к геометрической прогрессии, а значит, к стремительному падению рентабельности и конкурентоспособности проекта. Разве является это чей-то целью? Но если это не является ничьей целью, то почему эта проблема все еще существует и прогрессирует?

Причины здесь три:

1. Как говорил Кент Бек: "Краткосрочные индивидуальные цели часто конфликтуют с долгосрочными социальными целями. Общество решает эту проблему при помощи набора ценностей, подкрепленных мифами, ритуалами, наказаниями и наградами. Без уважения к этим ценностям люди забывают о социальных нуждах и стремятся реализовать свой собственный индивидуальный краткосрочный интерес."
-- "Extreme Programming Explained" 1st edition by Kent Beck, "Chapter 7. Four Values", перевод ООО Издательство "Питер"

В погоне за бизнес-выгодой в краткосрочной перспективе, часто жертвуются технические интересы долгосрочной перспективы.

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

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

3. Как ни банально это звучит, но имеет место элементарная нехватка как управленческой, так и технической грамотности, преодолению которой зачастую препятствует "Эффект Даннинга-Крюгера".

Как видите, для решения проблемы в масштабах отрасли, одного только недовольства ею недостаточно. Чтобы решить проблему, требуется:

1. Высокий уровень грамотности для анализа проблем, выявления точных целей и постановки эффективных задач. В данном конкретном случае требуется глубокое знание в Software Design, управлении процессами разработки и теории внедрения изменений.
2. Чистота и единство общих целей, высокий уровень морально-деловых качеств.
3. Консолидация индивидуальных усилий в организованную силу, способную преодолеть силы сопротивления, подпитывающие существование решаемой проблемы.

Именно на этих принципах и должно основываться объединение, созданное для решения проблем отрасли.

Как же можно решить проблему? Для её решения требуется изменить сложившиеся стереотипы и изменить общественное мнение. А для этого нужно привлечь массовое внимание к самой проблеме и способам её решения. К счастью, о решении этой проблемы было много написано, но, к сожалению, мало кем читано.

А для того, чтобы обладать потенциалом, достаточным для привлечения массового внимания, нужно консолидировать усилия лидеров общественного мнения, что и является задачей такого объединения. Почему, например, о "Неделе высокой моды" в Москве слышали многие, а о "Неделе качественного кода" не слышал никто? Разве с модой у нас дела обстоят хуже, чем с ежедневным количеством WTF на работе?

Мы решили эту ситуацию исправить и начать цикл тематических месячников с целью концентрации внимания общественности на конкретных проблемах и способах их решения.

#Goal

Друзья, спасибо за ответы. Честно говоря, было неожиданно наблюдать лидерство DDD под конец опроса. И все-таки, в конце "Принципы качественного кода" отыграли свое и сравняли счет. С них мы и начнем. Посвятим принципам качественного кода июль месяц.

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

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

#Trend

С чего начинается качественный код? Как говорил профессор Преображенский, разруха начинается с головы. И он был прав. Вернее, с «Закона Миллера»:

💬 «Магическое число семь плюс-минус два» («кошелёк Миллера», «закон Миллера») — закономерность, обнаруженная американским учёным-психологом Джорджем Миллером, согласно которой кратковременная человеческая память, как правило, не может запомнить и повторить более 7 ± 2 элементов.

Конечно, всегда найдутся желающие поспорить с Миллером, но только не Dijkstra:

💬 "The competent programmer is fully aware of the strictly limited size of his own skull; therefore, he approaches the programming task in full humility"
("хороший специалист всегда осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам с максимальной скромностью.")
—Edsger W. Dijkstra, 1972

И авторы KISS Principle с ним охотно согласились бы:

💬 "Be Humble, don't think of yourself as a super genius, this is your first mistake. By being humble, you will eventually achieve super genius status =), and even if you don't, who cares! your code is stupid simple, so you don't have to be a genius to work with it."
("Будьте скромны, не считайте себя супергением — это ваша первая ошибка. Оставаясь скромным, вы в конечном итоге достигнете уровня супергения, и даже если нет, какая разница. Ваш код должен быть прост настолько, что вам не нужно быть гением, чтобы работать с ним.")
—"KISS principle"

В принципе, «Закона Миллера» предопределяет потребность не только в качественном коде, но и в ставшей популярной в наши дни Team First Architecture.

#SoftwareDesign

Chat Digest

💬 Огненное видео от Майкла Нигорда:
- https://t.me/ru_arc_chat/1072

💬 Ряд мега-полезных файлов по архитектурной таксономии:
- https://t.me/ru_arc_chat/1062

💬 Атрибуты качества и их влияние на выбор архитектурного подхода к ядру системы:
- https://t.me/ru_arc_chat/998

💬 Architecture Characteristics Worksheet:
- https://t.me/ru_arc_chat/1005

💬 Матрица решений по выбору типа базы данных:
- https://t.me/ru_arc_chat/1052

💬 Архитектура = структуры + текстуры. Качество кода - это одна из текстур:
https://t.me/ru_arc_chat/972

💬 Про асинхронные и синхронные стили коммуникации:
- https://t.me/ru_arc_chat/956
- https://t.me/ru_arc_chat/935
- https://t.me/ru_arc_chat/896

💬 Чем отличается простой микросервис от BC?
https://t.me/ru_arc_chat/832

💬 Стратегические паттерны DDD:
- https://t.me/ru_arc_chat/813
- https://t.me/ru_arc_chat/821

💬 Чем отличается Бизнес-процесс от Workflow?
- https://t.me/ru_arc_chat/757

💬 Как легче всего думать о Бизнес-логике?
- https://t.me/ru_arc_chat/737

💬 С чего начинается EventStorming?
- https://t.me/ru_arc_chat/734

💬 Есть ли альтернатива для синхронных доменных событий в FP?
- https://t.me/ru_arc_chat/710

💬 Microservices and the First Law of Distributed Objects:
- https://t.me/ru_arc_chat/701

💬 Distributed transaction patterns for microservices compared:
- https://t.me/ru_arc_chat/691

💬 Ищут ли люди в споре истину?
- https://t.me/ru_arc_chat/651

💬 Какую проблему решают агрегаты и почему они возникли?
- https://t.me/ru_arc_chat/646

💬 Помогает ли EventStorming предотвратить ошибки при моделировании агрегатов?
- https://t.me/ru_arc_chat/636

💬 Если человек прав, то почему к нему не всегда прислушиваются?
- https://t.me/ru_arc_chat/628

💬 Какая роль микросервисов в топологии команд?
- https://t.me/ru_arc_chat/466

💬 Откуда легче всего начинать искать терминологию по Software Engineering:
- https://t.me/ru_arc_chat/441

💬 Как разрабатываются стандарты?
- https://t.me/ru_arc_chat/412

💬 Чем отличаются Architecture, Design и Implementation?
- https://t.me/ru_arc_chat/361

💬 Считает ли Robert C. Martin микросервисы архитектурой и все ли с ним согласны?
- https://t.me/ru_arc_chat/352

💬 О собеседованиях по System Design:
- https://t.me/ru_arc_chat/329

💬 Что не так с названием SRP, и почему он зачастую работает наоборот?
- https://t.me/ru_arc_chat/312

💬 Не могу заплатить за книгу. Что делать?
- https://t.me/ru_arc_chat/295

💬 Архитектурная ката победителей O'Reilly:
- https://t.me/ru_arc_chat/273

💬 О метамоделях:
- https://t.me/ru_arc_chat/270

💬 Что читать по DDD?
- https://t.me/ru_arc_chat/268

💬 Каталоги и матрицы устарели и не соответствуют вызовам времени. Что применить взамен?
- https://t.me/ru_arc_chat/250

💬 Метамодель GoF:
- https://t.me/ru_arc_chat/246

💬 Шаблоны стабильности от Майкла Нигорда:
- https://t.me/ru_arc_chat/241

💬 Читать ли синюю книгу от Эванса? Не устарела ли она?
- https://t.me/ru_arc_chat/235

💬 Мега-статья о жертвенной архитектуре:
- https://t.me/ru_arc_chat/161

💬 Почему не все проекты успешны?
- https://t.me/ru_arc_chat/160

💬 Эффект новизны Хотторна от изучения новых технологий:
- https://t.me/ru_arc_chat/159

#ChatDigest

👀 Новое видео на канале!
Топ жести на собеседовании: https://youtu.be/KdmYL8TJEIA

Что делают большинство разработчиков, когда им нужно провести собеседование? Правильно, гуглят 100 вопросов на собеседование на ${любимый_язык}. А потом мы все жалуемся, что на собеседованиях творится какая-то вакханалия.

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

🙏 Не забудьте поставить лайк и подписаться на YouTube канал, если видео вам понравилось!

Проще всего пояснить "Закон магического числа 7 ± 2" этой картинкой☝️(кликните для увеличения). Как говорится, лучше один раз увидеть. Такой же процесс происходит, когда уровень сложности рассматриваемого фрагмента кода превышает возможности краткосрочной памяти человека.

Просто ваши глаза не могут увидеть все 12 точек одновременно. Ninio's extinction illusion. Twelve black dots cannot be seen at once. Ninio, J. and Stevens, K. A. (2000) Variations on the Hermann grid: an extinction illusion. Perception, 29, 1209-1217.

#SoftwareDesign

Какую же задачу решает качественный код?

💬 "Nothing kills speed more effectively than poor internal quality."
—"Planning Extreme Programming" by Kent Beck, Martin Fowler

💬 "... the activity of design is not an option. It must be given serious thought for software development to be effective."
—"Extreme Programming Explained" by Kent Beck

💬 "The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times."
—"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin

💬 "In most contexts higher quality ⇒ expensive. But high internal quality of software allows us to develop features faster and cheaper."
—"Tradable Quality Hypothesis" by Martin Fowler

💬 "The value of good software design is economic: you can continue to add new functionality quickly even as the code-base grows in size."
—"Design Stamina Hypothesis" by Martin Fowler

💬 "The fundamental role of internal quality is that it lowers the cost of future change. But there is some extra effort required to write good software, which does impose some cost in the short term."
—"Is High Quality Software Worth the Cost?" by Martin Fowler

💬 "The whole point of good design and clean code is to make you go faster - if it didn't people like Uncle Bob, Kent Beck, and Ward Cunningham wouldn't be spending time talking about it."
—"Technical Debt Quadrant" by Martin Fowler

💬 "If you're a manager or customer how can you tell if the software is well designed? It matters to you because poorly designed software will be more expensive to modify in the future."
—"Is Design Dead?" by Martin Fowler

Сама по себе скорость разработки - это еще не цель. Это только задача в достижении цели.

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

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

#SoftwareDesign

О том же самом от редкого Мастера слова - Kent Beck:

📝 "Сделайте изменение легким, а потом делай легко изменение.

Make the change easy then make the easy change."

—Kent Beck, "Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 2020"

#SoftwareDesign

Сегодня Big Design Up Front (BDUF) даже в проектах средней величины практически не применяется. Обрабатывать неопределенность заблаговременно (Prediction), путем логического вывода - это очень дорогая задача, стоимость которой может достигать экспоненциального роста по мере повышения точности прогнозирования (по крайней мере, по утверждению Robert C. Martin). В то время как бизнес-выгоды от этой точности возрастают куда скромнее, вплоть до логарифмического характера. Иными словами, нельзя повышать точность прогноза до бесконечности - у него есть предел экономической целесообразности.

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

💬 "To deal with the issues of incompletely known requirements and inaccurate estimates, a number of other types of models have been proposed: incremental, spiral, iterative, and evolutionary (adaptive)."
—"ISO/IEC/IEEE 12207:2017 Systems and software engineering - Software life cycle processes"

Тут мы подошли к той самой причине, по которой сегодня во всех крупных проектах применяются модели разработки, производные от итеративно-инкрементальной модели - они позволяют обрабатывать неопределенность эмпирически, т.е. опытным путем, вместо Prediction используя Adaptation. Выдвинули гипотезу, реализовали её в виде небольшого системного инкремента, проверили на практике, выявили отклонения и адаптировали систему - это и составляет основу итерации.

💬 "Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements...

I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.

Therefore one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements."
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.

Каким же образом распространение эмпирического способа разрешения неопределенности отразилось на архитектуру?

Если раньше основным фокусом архитектуры считалось предвидение развития системы (Prediction):

💬 "Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other." — Ralph Johnson

То теперь её фокусом стала изменяемость (Adaptation), т.е. максимизация открытых решений, где их открытость определяется стоимостью их изменения:

💬 "A good architect pretends that the decision has not been made, and shapes the system such that those decisions can still be deferred or changed for as long as possible. A good architect maximizes the number of decisions not made."
—"Clean Architecture: A Craftsman's Guide to Software Structure and Design" by Robert C. Martin

Если вдруг кто не помнит - именно Robert C. Martin организовал Snowbird встречу 2001 года по Agile Manifesto.

Про смену фокуса говорится и в стандарте:

💬 "The incremental and iterative nature of Agile development can facilitate efficient technical and management processes and practices to reduce the cost associated with change. In comparison, projects managed at the waterfall end of the continuum seek to reduce total rework cost by minimizing the number of changes, limiting the number of control points, and baselining detailed specifications which are reviewed and traced throughout the project."
—"ISO/IEC/IEEE 12207:2017 Systems and software engineering - Software life cycle processes"

Забегая наперед, скажем, что не все так просто, и:

💬 "Agile Architecture shall seek a balance between intentional and emerging."
—"Open Agile Architecture™" by The Open Group, Chapter "9.14. Axiom 14. Bias for Change"

#SoftwareArchitecture #Agile #SDLC

В предыдущем посте проскочил термин Agile. Да и в чате канала тоже этот термин не был обделен вниманием. Вероятно, теперь самое время разобраться с тем, что это такое. Удивительно, но будучи одним из самых обсуждаемых терминов, он остается одним из самых непонятных для многих.

💬 "Agile development - software development approach based on iterative development, frequent inspection and adaptation, and incremental deliveries, in which requirements and solutions evolve through collaboration in cross‐functional teams and through continual stakeholder feedback."
—"ISO/IEC/IEEE 12207:2017 Systems and software engineering - Software life cycle processes"

А вот, что говорит сам Jeff Sutherland - сооснователь Scrum:

💬 "Scrum is, as the reader supposedly knows, an agile method. The agile family of development methods evolved from the old and well-known iterative and incremental life-cycle approaches. They were born out of a belief that an approach more grounded in human reality – and the product development reality of learning, innovation, and change – would yield better results."
—"Jeff Sutherland's Scrum Handbook" by Jeff Sutherland

Agile модель разработки расширяет итеративно-инкрементальную модель и привносит в нее еще ряд психологически-философских принципов с целю устранения напряжения между представителями бизнеса и техническими специалистами. Но основное назначение остается прежним - разрешение неопределенности опытным путем (Adaptation):

💬 "No crystal balls. Humans are not able to predict the future. For example, your competition makes an announcement that was not expected. Unanticipated technical problems crop up that force a change in direction. Furthermore, people are particularly bad at planning uncertain things far into the future – guessing today how you will be spending your week eight months from now is something of a fantasy. It has been the downfall of many a carefully constructed Gantt chart."
—"Jeff Sutherland's Scrum Handbook" by Jeff Sutherland

Ладно, Jeff Sutherland - заинтересованное лицо. Он может быть субъективен, да и не все архитекторы его жалуют, а некоторые даже считают его угрозой для архитектуры. Послушаем лучше Gregor Hohpe:

💬 "Agile methods are most valuable when we're dealing with high levels of uncertainty."
—"Agile and Architecture: Friend, not Foe" by Gregor Hohpe

Ну и нельзя обойти в вопросе "Предвидеть" vs "Адаптировать" известную статью на эту тему:
"The New Methodology :: Predictive versus Adaptive" by Martin Fowler

#Agile #SDLC

"Забудьте САР теорему как более не актуальную" - перевод бомбовой статьи Martin Kleppmann от @kwiscakh

Уже не ново, но как никогда актуально.
#DistributedSystems