На Snowbird meeting обсуждались принципы "Bill of Rights", один из которых гласит:

📝 "You [programmer] have the right to produce quality work at all times."

Причем:

📝 "During the Snowbird meeting, Kent Beck said that the goal of Agile was to heal the divide between business and development."
-- "Clean Agile: Back to Basics" by Robert C. Martin - организатор той встречи.

Недавно состоялся опрос, по результатам которого выяснилось, что 20% участников опроса демотивированы загниванием кода по причине отсутствия понимания со стороны Product Owner (Project Manager). Эту проблему хорошо освещали многие известные авторы: Kent Beck, Robert Martin, Jeff Sutherland, Martin Fowler, Craig Larman, Henrik Kniberg, Dean Leffingwell, Kenneth Rubin, Ward Cunningham и другие.

Как могло получиться, что, используя Agile, разработчики, вместо "produce quality work at all times", вынуждены копаться в коде, который по своей консистенции не сильно отличается от свалки? Терпения на такие "условия работы" хватает не у всех, что является одной из распространенных причин текучки кадров.

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

Это только одна из многих проблем, которые мы наблюдаем в отрасли, и для решения которых мы и решили объединить усилия в этом канале.

Знакома ли вам эта проблема? Удалось ли её решить? Каким образом?

#SoftwareDesign #SDLC #Goal

Про оценивание задач:
- "Practice Standard for Scheduling" 3d edition by Project Management Institute
- "Software Estimation: Demystifying the Black Art (Developer Best Practices)" by Steve McConnell (я встречал в интернете краткий конспект)
- "Agile Estimating and Planning" by Mike Cohn

Очень кратко (всего 3 страницы) о методике оценивания PERT:
- "The Clean Coder" by Robert C. Martin, "Chapter 10 Estimation :: PERT"

Статья, отвечающая на очень частый вопрос:
- "How Do Story Points Relate to Hours" by Mike Cohn

#Estimation

"Help geeks feel safe in the world" - карьерная миссия Kent Beck очень близка целям нашего объединения. На прошлой неделе он посвятил этому вопросу целую статью: "Help Geeks Feel Safe In The World: My Personal Mission".

Роль Kent Beck в индустрии сложно переоценить: Design Patterns, xUnit, TDD, Refactoring, Extreme Programming и существенное влияние на Agile Manifesto. Невероятно эрудированный человек, обладающий редкой способностью объяснять сложные вещи простым языком.

#Goal

Мы продолжаем информировать вас о целях нашего объединения, поскольку, как говорится, важно не объединение само по себе, а те принципы, на которых оно основано. Сообщения о наших целях мы будем помечать тегом #Goal .

Как говорил Gregor Hohpe:

"There's a definite Dunning-Kruger effect for authors.
The people who hold a ton of knowledge hesitate because they find their insights "obvious" or "nothing special".
Then you have people who write a lot but do little real work that they could base their writing on..."

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

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

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

#Goal

Список рекомендуемой литературы от Gregor Hohpe:
1. "The Architect's Path (Part 1 - Model)"
2. "The Architect's Path (Part 2 - Implementation)"

#SoftwareArchitecture

Большинство книг, которые рекомендует Грег, с моей точки зрения, не для "новичков" в профессии и не дают знания которые нужны "прямо" сейчас на нашем рынке. Лично я полагаю, что многие из этих книг точно стоит прочесть, но наверно во 2-й или 3-й очереди.

Это ресурсы для 1-ой очереди изучения, то есть базовые, необходимые в первую очередь.

В перечне только актуальные и "свежие" ресурсы.

Блоги:
https://martin.kleppmann.com/
https://berndruecker.io/
https://architectelevator.com/

Каталоги паттернов:
https://www.enterpriseintegrationpatterns.com/
https://microservices.io/

Базовые знания:
https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable-ebook/dp/B06XPJML5D/
https://www.amazon.com/Balancing-Coupling-Software-Design-Addison-wesley/dp/0137353480

DDD:
https://www.amazon.com/Learning-Domain-Driven-Design-Aligning-Architecture/dp/1098100131/

Микросервисная архитектура:
https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543/

Workflow Management:
https://www.amazon.com/Practical-Process-Automation-Orchestration-Microservices/dp/149206145X/

Исследование предметной области:
https://www.eventstorming.com/

Архитектурные фреймворки:
https://pubs.opengroup.org/architecture/o-aa-standard/

Методологии разработки и орг архитектура:
https://teamtopologies.com/

Важнейшие статьи:
https://martinfowler.com/articles/architect-elevator.html
https://martinfowler.com/bliki/MonolithFirst.html
https://martinfowler.com/bliki/SacrificialArchitecture.html

Немного профессионального юмора 🙂:
"in Italian the word Domain translates into Dominio that means also Domination with possibly bizarre consequences."
-- Alberto Brandolini

"Actually, we use the term “activity” because the word “task” means something completely different in Swedish. :o)"
-- Henrik Kniberg

#SDLC #DDD

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

I. Putting the Model to Work

Domain-­Driven Design is an approach to the development of complex software in which we:

1. Focus on the core domain.
2. Explore models in a creative collaboration of domain practitioners and software practitioners.
3. Speak a ubiquitous language within an explicitly bounded context.

This three-­point summary of DDD depends on the definition of the terms, which are defined in this booklet.
Many projects do modeling work without getting much real benefit in the end. The patterns of DDD distill successful practices from projects where dramatic benefits have come from modeling. Taken together, they lay out a quite different approach to modeling and software development that runs from fine details to high-­level vision. Rigorous modeling conventions must be balanced with free exploration of models in collaboration with non-­technical people.
Tactics and strategy must be combined to succeed, and DDD addresses both tactical and strategic design.

-- "Domain-Driven Design Reference" by Eric Evans

#DDD

​​Биометрия шагает в массы

Официально опубликованы:

• Постановление Правительства Российской Федерации от 15.06.2022 № 1066 «О размещении физическими лицами своих биометрических персональных данных в единой информационной системе персональных данных, обеспечивающей обработку, включая сбор и хранение, биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным физического лица».

• Постановление Правительства Российской Федерации от 15.06.2022 № 1067 «О случаях и сроках использования биометрических персональных данных, размещенных физическими лицами в единой информационной системе персональных данных, обеспечивающей обработку, включая сбор и хранение, биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным физического лица».

Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов

#DDD #Microservices

Читал на днях книгу Alberto Brandolini "Leanpub: Introducing EventStorming", где он говорит о распространенной ловушке моделирования агрегатов, когда на него возлагают функции Read Model:

📝 "A shopping cart will include the list of the items to be purchased, with the associated quantity and price.

Bread and butter, apparently, except that we now should be asking ourselves whether we need to include the ItemDescription in the ItemInCart. Feels like we should, because we’ll need to display the ShoppingCart info to the customer, in order to review the cart before proceeding to checkout “is this really the stuff you intended to buy? Have you looked at the grand total?”. Things might get awkward when starting to consider events like ItemPriceUpdated or ItemDescriptionUpdated, that should have us thinking whether we should include a copy of the entire description of the selected item, or just a reference to the Item in stock.

Hmmm… not. Sorry for the detour, but these are not the aggregates we’re looking for. “data to be displayed to a user in order to make a decision” will be a Read Model. Aggregates are something else, but we have to be aware of this vicious temptation of superimposing what we need to see on the screen on the internal structure of our model."
-- "Leanpub: Introducing EventStorming" by Alberto Brandolini

#DDD #Microservices

Две статьи о том, что проблема гонки сообщений в шине может решаться на уровне бизнес-логики. Одна из них - от 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