Мы решили объединить усилия в новом коллективном телеграм-канале, посвященном вопросам ИТ-архитектуры и управления процессами разработки.

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

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

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

Канал самоуправляется консенсусом коллегии из пяти человек: @sergey486 , @GKruglov , @elukianov , @easlamov и @emacsway . Круг авторов этим не ограничивается. Если вы поддерживаете наши устремления и обладаете необходимыми навыками, то можете пополнить наш авторский коллектив (обращайтесь к любому из списка).

Для обсуждений создан чат: https://t.me/ru_arc_chat

Это только первый шаг. Уже сейчас мы продумываем принципы, которые позволят коллективизировать работу над архитектурными руководствами, а так же над Reference Architectures/Applications. Есть и другие идеи, но о них говорить пока еще преждевременно. В общем, должно получиться интересно.

#Goal

Групповое мышление (Groupthink) — психологический феномен, которому многие подвержены, но о котором немногие подозревают. Он объясняет, почему групповое решение вовсе не обязательно приводит к сбалансированному, взвешенному и правильному решению.

Пара неплохих статей на ресурсе Atlassian о роли когнитивных искажений в Decision-Making:

- "5 cognitive bias examples and how to avoid them in decision-making"

- "Reading this decision-making article is the best decision you’ll make today"

Интересно то, что автор затронул одну из наиболее острых тем "Think through short-term and long-term effects". На эту же тему писал Craig Larman в статье "Системное мышление".

В общем, в нашу эпоху Team First Architecture, психология стала неотъемлемой частью архитекторской работы.

На всякий случай, шпаргалка по когнитивным искажениям в виде мобильного приложения - вдруг кому пригодится:
- https://play.google.com/store/apps/details?id=ru.free_coding.biascs

#Psychology

"Developer to Architect :: Training and resources for the journey from software developer to software architect"
by Mark Richards, Software Architect and Founder
- https://www.developertoarchitect.com/lessons/

#SoftwareArchitecture

Mo - Monads and popular FP abstractions, powered by Go 1.18+ Generics (Option, Result, Either...)
- https://github.com/samber/mo

#FunctionalProgramming #Golang

На 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