Сегодня в 18:00 по Москве на Youtube мы продолжим обсуждение книги Technology в рамках клуба Code of Architecture.
У нас в гостях будет Евгений Пешков из ЦИАН. Евгений - техлид, который занимается управлением и развитием команд разработки. Развивает сообщество DDD-практиков, интересуется всем, что связано с technical excellence.

В этот эпизоде мы начнем обсуждать третью часть книги "Communicating the Strategy", в которой автор говорит о том, что помимо создания стратегии нам надо уметь ее правильно коммуницировать иначе какой бы отличной она не была, это нам не поможет. И если во второй части мы учились ее разрабатывать, то в этой части будем учиться доносить ее ценность. А начнем мы с главы "Approach Patterns", в которой представлены следующие паттерны
- 30-Second Answer - вариант речи в лифте, когда мы должны за 30 секунд успеть емко и четко ответить на вопрос топ-менеджера
- Rented Brain - автор предлагает научиться думать в парадигме привлеченных консультантов. Кстати, я как-то уже рассказывал про книгу "I'm Sorry I Broke Your Company: When Management Consultants Are the Problem, Not the Solution", в которой консультант рассказывает подробнее как они работают и как могут приносить пользу
- Ars Rhetorica - автор предлагает вернуться к корням и вспомнить про риторику, про которую писал еще Аристотель. где он говорил про способность находить способы убеждения относительно любого предмета. Я уже как-то рассказывал про свое впечатление от прочтения Риторики Аристотеля.
- Fait Accompli - подход про предпродажу крупных изменений в рамках 1-1 встреч с основными стейкхолдерами перед большой отчетной встречей
- Dramatic Structure - история про драматическую структуру и отсылка к сюжетю голивудских фильмов (интересно, что можно копнуть глубже и дойти до тысячеликого героя Кэмпбелла, хотя автор про это и не говорит - подробнее про Кэмпбелла можно прочитать в заметке). А если интересна тема написания сценариев, то можно почитать еще каноническую книгу "Memo. Секреты создания структуры и персонажей в сценарии", про которую я писал на Medium
- Deconstruction - заумная история про семиотику, знания, знаки и семантику. Здесь автор приводит фреймворк для решения проблем так, чтобы в итоге получился шаблон решения конкретной проблемы, который позволит вам исключить себя из процесса ее решения.
- Scalable Business Machine - подходы к построению масштабирующегося бизнеса. Тут автор интересно рассказывает про свой подход, в котором он поминает про техническе принципы к дизайну систем, навроде fit for puprose и fit for use (подробнее в статье с моим обзором книги "Software Architecture for Busy Developers"), также говорит про SOLID и что его можно использовать в проектировании бизнеса (я тоже как-то рассказывал про подход SOLID к техническому менеджменту), вспоминает про Чарльза Дарвина с его происхождением видов и приходит к тому, что история компании имеет значение (про это можно интересно почитать в книге "The Corporate Tribe", про которую я уже писал раньше). Дальше автор дает определения составляющим частям Scalable Business Machine и рассказывает как за 15 шагов ее построить.

#SoftwareArchitecture #Strategy #Patterns

В этот четверг, 24 ноября, мы провели четвертый стрим по книге “Technology Strategy Patterns”.
В этом эпизоде мы начали обсуждать часть “Communicating the Strategy” и обсудили седьмую главу “Approach Patterns”.
Гостем стрима был Евгений Пешков из Циан. Он управляет и развивает команды разработки и сообщество DDD-практиков. Интересуется всем, что связано с technical excellence.

Артефакты с этого стрима доступны по ссылкам
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией
Если вы пропустили первые серии, то можете прочитать их здесь: 1, 2, 3.

Ждем вас в этот четверг, где мы продолжим обсуждать эту книгу.

#SoftwareArchitecture #Strategy #ExternalReview #Patterns

Сегодня вечером в 18:00 по Москве мы в рамках очередного выпуска клуба "Code of Architecure" закончим обсуждать часть, посвященную "Communicating the Strategy", а также всю книгу "Technology Strategy Patterns" целиком. Гостем стрима будет Игорь Курочкин - эксперт в enabling.team, помогает CTO развивать платформенные и продуктовые команды.

В этом эпизоде мы рассмотрим последние три главы
В восьмой главе "Templates" автор расскажет про 8 шаблонов, которые помогут вам так рассказать о вашей стратегии, чтобы ее "купили":
- One-Slider - шаблон для того, чтобы представить все на одном слайде так, чтобы это было понятно как топ-менеджерам, так и вашим командам
- Use Case Map - декомпозиция ваших инициатив до конкретной ценности для ваших конечных пользователей
- Directional Costing - паттерн для того, чтобы уметь давать оценки вашим инициативам или инициативам топ-менеджеров, которые вас попросили оценить
- Priority Map - простой подход для приоритизации ваших Use Cases, которые вы отобразили на Use Case Map
- Technology Radar - инструмент для визуализации ваших технологических решений и используемых инструментов, а также инструмент для их governance
- Build/Buy/Partner - подход для оценки преимуществ и недостатков покупки софта, создания его самим или в партнерстве
- Due Diligence - подход к оценке того, что вы планируете купить или для внутреннего использования, чтобы оценить насколько ваш продукт привлекательно смотрится в рамках Due Diligence и какие есть точки роста
- Architecture Definition - подход к осмысленной работе над архитектурой ваших систем, чем-то напоминает историю с RFC и ADR

В девятой главе "Decks" автор рассказывает о том, как составлять ваши выступления для публики. Он рассказывает про шесть подходов
- Ghost Deck - подход к созданию презентаций, начиная с заголовков слайдов и двигаясь дальше к сути
- Ask Deck - подход к тому, как делать презентации, в которых вы запрашиваете что-то, например, ресурсы на свою очередную светлую идею
- Strategy Deck - кратко про то, как готовить презентацию со стратегией (спойлер: применить большинство паттернов из этой книги и дальше объединить их результаты)
- Roadmap - подход для составления дорожных карт с использованием Backcasting и других паттернов как следующий в списке
- Tactical Plan - упрощенный подход к составлению планов, навроде, плана проекта из стандартного подхода к управлению проектами
- MergeSort Meeting - подход к тому, как проводить общие встречу не в лоб через BrainStorming, а более эффективно

В последней главе "Bringing It All Together" автор показывает как все паттерны связаны между собой и группирует их в три уровня по вариантам использования:
- Individually - паттерны, которые могут принести пользу по одиночке
- In clusters - паттерны, которые полезны, когда группируются вместе
- Comprehensively - паттерны, которые полезны только когда применяются с большинством других паттернов из этой книги

На этом книга заканчивается и мы остаемся с огромным набором инструментов и знаний, которые могут помочь нам стать лучше как технологические стратеги:)

#SoftwareArchitecture #Strategy #Patterns

В этот четверг, 1 декабря, мы провели последний стрим по книге “Technology Strategy Patterns”, в котором мы закончили ее обсуждение.
В этом эпизоде мы обсудили последние три главы "8. Templates", "9. Decks", "10. Bringing It All Together"
Гостем стрима был Игорь Курочкин — эксперт в enabling.team, который помогает CTO развивать платформенные и продуктовые команды.

Артефакты с этого стрима доступны по ссылкам
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией
Если вы пропустили первые серии, то можете прочитать их здесь: 1, 2, 3, 4.

P.S.
На этом эта книга заканчивается и мы остаемся с огромным набором инструментов и знаний, которые могут помочь нам стать лучше как технологические стратеги:)

#SoftwareArchitecture #Strategy #ExternalReview #Patterns

AWS re:Invent 2022 - Keynote with Dr. Werner Vogels

Интересное выступление CTO Amazon.com, которое начинается с антуража матрицы и заканчивается призывом делать симуляции всего вокруг.
А внутри двухчасового выступления Верненр Фогель, в футболке с лямбда на груди, рассказывает об асинхронном мире вокруг и преимуществах создания асинхронных систем, которые учитывают это.
Он говорит про concurrency и parallelism и приводит примеры из дизайна распределенных систем, а точнее принципов, по которым было построено AWS S3 в свое время.
Рассказывает про эволюцию архитектуры самого Amazon через стадии Monolith -> SOA -> Microservices -> Shared Services
Вернер дает ссылку на документ 1998 года, который назывался Amazon Distributed Computing Manifesto и говорит, что уже почти 25 лет назад инженеры Amazon думали про наш распределенный мир. И если заглянуть в статью, то видно, что именно этот подход привел к тому, что в 2004 году он пообщавшись с ними стал их CTO на следующие 18 лет.
Дальше он рассказывает про работу workflow рассказывает про сервисы AWS Step Functions и AWS Event Bridge и их расширения.
И после этого он переходит к песне про Event Driven Architecture (EDA) про loosely coupled architecture, которое позволяет создавать системы, которые могут эволюционировать.
И дальше достаточно долго речь идет про то, как делать EDA на иструментах от AWS.
Интересно, что в процессе автор рассказывает про инструмент Amazon Builders Library, который является аналогом книги GoF про паттерны, но только от инженеров AWS и в контексте инструментов от AWS (надо будет почитать статьи оттуда).
Дальше автор анонсирует Amazon Code Catalyst для ускорения создания приложений для AWS, где объединен ваш код, CI/CD, issues и так далее.
Ну и заканчивается все переходом к 3D и моделированию окружающего мира, что закольцовывает выступление, которое начиналось с симуляции аля матрица.

#Architecture #SoftwareArchitecture #AWS #Patterns #EDA #Microservices #Technology #Conference

Code of Architecture - Kubernetes Patterns, 2nd Edition

В голосовании на выбор новой книги победило второе издание "Kubenetes Patterns", что вышло в марте 2023. В ближайшее время мы начнем ее читать и планируем управиться за три-четыре выпуска. Если вам интересна эта тема, то для вас есть пара ресурсов, что могут быть полезны
- Бесплатная версия ebook от RedHat доступна здесь
- Мой обзор первого издания книги есть в статье. Во втором издании добавилась часть про security patterns и была сильно отредактирована часть про advanced patterns (про elastic scale и image builder)
- Поверх Kubernetes стали строиться платформы и про эту концепцию можно посмотреть интервью Mauricio Salatino, автора книги "Platform Engineering on Kubernetes", про которое я писал раньше

#Kubernetes #SoftwareArchitecture #Software #Architecture #Patterns #DIstributedSystems

2. The Patterns - а здесь приводятся паттерны для решения стандартных проблем из областей, разобранных в первой части
- Domain Logic Patterns - здесь речь идет про transaction script (для простой бизнес-логики), domain model, table module, service layer, которые мы обсуждали чуть выше
- Data Source Architectural Patterns - здесь разбираются такие паттерны как: table data gateway, row data gateway, active record,
data mapper
- Object-Relational Behavioral Patterns - здесь приводятся поведенческие паттерны вида: unit of work, identity map, lazy load
- Object-Relational Structural Patterns - здесь разбирается очень много структурных паттернов, многие из которых завязаны на работу с данными, identity field, foreign key mapping, association table mapping, dependent mapping, embedded value, serialized LOB. А также целый набор паттернов для решения проблемы хранения информации о иерархиях наследования в реляционной базе: single table inheritance, class table inheritance, concrete table inheritance, inheritance mappers
- Object-Relational Metadata Mapping Patterns - паттерны для хранения метадаты о связи классов и сущностей в базе: metadata mapping, query object, repository
- Web Presentation Patterns - куча паттернов про представление, но из практики, что была актуальна 20 лет назад: model view controller, page controller, front controller, template view, transform view, two step view, application controller. Если и читать это, то ради исторического экскурса:)
- Distribution Patterns - всего два паттерна для решениия вопроса распределенных объектов: remote facade, DTO (data transfer object)
- Offline Concurrency Patterns - паттерны для работы с конкурентностью: optimistic offline lock, pessimistic offline lock, coarse-grained lock, implicit lock
- Session State Patterns - паттерны относительного хранения состояния сессии клиента: client session state, server session state, database session state
- Base Patterns - базовые паттерны, что не влезли в другие категории: gateway, mapper, layer supertype, separated interface, registry, value object, money, special case, plugin, service stub, record set. Эти паттерны являются достаточно простыми и часто применяются в разных сценариях.

В общем, книга для 2002 года была просто огонь - она рассказывала про подходы к проектированию и решение типовых проблем. Также в рамках серии книг Martin Fowler Signature были выпущены и другие книги, которые развивали эту тему. Например, книга "Enterprise Integration Patterns (Шаблоны интеграции корпоративных приложений)", про которую я рассказывал раньше. Ну а сейчас книга скорее является базой, которую многие изучают по другим книгам, которые вышли позже и рассказывают про актуальные паттерны в контексте конкретной платформы (Java, Kotlin, .Net, Python, ...) и делают это супердоступно.

#Patterns #Software #SoftwareArchitecture #SoftwareDevelopment #Architecture #SystemDesign

Типичные ошибки проектирования (Bug Patterns In Java)

Эта книга из начала моей карьеры. На английском она вышла в 2002 году, а уже в 2003 году издательство Питер применило креатив при переводе и "Bug Patterns in Java", которые можно было перевести как паттерны багов в Java превратилась в типичные ошибки проектирования:) Но несмотря на креатив в названии, книга показалась мне тогда полезной и объемной. В ней всего 23 части
1. Agile Methods in a Chaotic Environment - здесь речь шла про гибкие подходы, концепцию паттерно в общем в и паттернов багов конкретно, а также зачем их изучать
2. Bugs, Specifications, and Implementations - объяснение как понять что такое баг, а что такое фича. После прочтения легко становится понятна фраза "Это не баг, это фича":)
3. Debugging and the Development Process - как отлаживаются программы, про парное программирование, про общее владение кодом и про написание тестов для "всего, что может сломаться"
4. Debugging and the Testing Process - как писать тестируемые программы, про статический контроль типов, правильные абстракции и инкапсуляцию, хорошие интерфейсы
5. The Scientific Method of Debugging - обсуждение научного подхода к дебагу - наблюдение, построение гипотез, проверка гипотез при помощи экспериментов, повторение этих шагов в цикле, пока не исправим проблему
6. About the Bug Patterns - расказ про важность паттернов багов, объяснение как выглядит такой антипаттерн и большой справочник по отладке программ
7. The Rogue Tile - это антипаттерн фальшивая черепица, в котором программа после исправления ведет себя так, как будто баг не был исправлен. Причина может быть в том, что проблемная логика растиражирована внутри приложения и ее нужно вынести в общее место и починить один раз там:)
8. Null Pointers Everywhere! - стандартная история с Java:)
9. The Dangling Composite - болтающийся компонент, который характерен для рекурсивно определенных типов данных, где некоторым базовым случаям не выделяются классы, а используются null pointers
10. The Null Flag - когда программа вместо выкидывания значимого исключения кидает null pointer exception.
11. The Double Descent - проблема с рекурсивным обходом составной структуры, когда мы прыгам более чем на один щаг вниз
12. The Liar View - антипаттерн "лживое представление" на случай, когда используется паттерн MVC и работа представления и модели расходится
13. Saboteur Data - история про косяки с валидацией входных данных и дальнейшим их использованием внтури приложения
14. The Broken Dispatch - косяки с полиморфизмом и перегрузкой методов
15. The Impostor Type - тип-самозванец, когда программа одинаково обрабатывает принципиально разные типы данных. Про такую проблему рассказывал Джон Остерхут в книге "A philosophy of software design" как о проблеме, которую он пытался найти полгода:)
16. The Split Cleaner - проблемы при некорректном управлении ресурсами, когда они или не освобождаются или наоборот делают это слишком рано
17. The Fictitious Implementation - проблема, когда реализация интерфейса не удовлетворяет некоторым содержащимся в нем инвариантам
18. The Orphaned Thread - проблема в многопоточном приложении, когда потоки остановились в ожидании данных от поттока, что прекратил свою работу
19. The Run-On Initialization - проблема при инициализации атрибутов класса, когда конструктор инициализировал не все из них
20. Platform-Dependent Patterns - платформо-зависимые ошибки
21. A Diagnostic Checklist - список вопросов и симптомов некорректного поведения, который можно использовать для дебага
22. Design Patterns for Debugging - паттерны проектирования, которые помогают в отладке (первый паттерн в использовании статической типизации)
23. References - ссылки на ресурсы, что были полезны 20 лет назад:)

#Software #SoftwareArchitecture #Patterns #Design #Architecture #SoftwareDevelopment #Engineering

Growing Your Personal Design Heuristics • Rebecca Wirfs-Brock • YOW! 2019 - Part 1

Посмотрел на днях выступление за авторством Rebecca Wirfs-Brock, заслуженной бабушки, что написала две книги: "Designing Object-Oriented Software" в 1990 и "Object Design: Roles, Responsibilities, and Collaborations" в 2003. Она является изобретателем Responsibility-Driven Design, одного из первых поведенческих подходов к объектному дизайну. В итоге, если вы слышали про X-driven design (XDD), где X - это произвольное слово, то можете поблагодарить Ребекку за то, что она проложила эту дорожку.

В этом выступлении Ребекка рассказывает про эвристики, как они помогают принимать дизайн решения и как собрать осмысленно свой набор эвристик. Речь идет про
- Кулинарные рецепты, в которых инструкции недостаточно точны, чтобы следуя им напрямую получить желаемое блюдо
- Потом следует вывод, что не существует замены для обучения на своем собственном опыте и рефлексии относительно него
- Дальше автор разбирает то, что такое эвристика и разбирает четыре варианта: rule of thumb, practical method, useful shortcut, approximation. И бракует пару последних вариантов. В итоге, ее определение близко с определениями из wikipedia

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

- Следом за этим Ребекка начинает погружаться в примеры эвристик из разных областей и вспоминает про Мартина Фаулера с его эвристикой для структурирования domain layer, где он предлагал много лет назад три варианта: transaction script pattern, table module pattern, domain model pattern. И Ребекка откапывает тут стюардессу для того, чтобы показать, что эвристики устаревают со временем, так как state-of-the-art постоянно прогрессирует и мы сталкиваемся с новыми проблемами и придумываем новые эвристики для решений. Тут она показывает и другой набор эвристик для дизайна и вспоминает про хранимую процедуру со 100 входными параметрами, которую ей когда-то пришлось ревьювить:) В итоге, следует вывод, что между эвристиками и их пользователями всегда будут нестыковки и надо уметь договариваться.
- Поговорив про эвристики для дизайна, Ребекка переходит к обсуждению мета-эвристик, а точнее эвристик для использования других эвристик. Тут приводится пример с разделением команд, паттерн для первого контакта с системой.
- Следующим шагом идет эвристика, которая определяет наше поведение и отношение к происходящему. Для себя Ребекка вывела эвристику, что она ценит больше консистентность, а не ум. Интересно, что еще в школе я видел похожую эвристику у своего учителя по физике (ниже история скрыта за спойлером)
В лицее у меня был учитель по физике, который выучил кучу призеров международных олимиад по физике. Его эвристика по оцениванию учеников была примерно такой: "Я ценю больше старание и усилия, чем ум". Так у меня в школе итоговой оценкой по физике от него стала четверка и это с учетом учебы в 10 и 11 классе в ЗФТШ и поступление в МФТИ. Просто я был недостаточно сфокусированным на саморазвитии в области физики:)
- Для того, чтобы эвристики не протухали, их требуется переодически испытывать на прочность. Дальше Ребекка обсуждает эвристики насчет размера микросервисов - в 2019 году это было горячей темой:)

А алгоритм для развития эвристик будет в отдельном посте, так как в этот он не поместился:)

#Management #Software #SoftwareDevelopment #Patterns #Engineering #SelfDevelopment

Growing Your Personal Design Heuristics • Rebecca Wirfs-Brock • YOW! 2019 - Part 2

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

1) Она рекомендует составить карту своих интересов, а дальше пошарить и обсудить свои любимые эвристики с экспертами в этих темах - это позволяет проверить свои эвристики на прочность, понять их границы применимости и получить новых эвристик. Для записи эвристик Ребекка предлагает использовать технику, что похожа на описание паттернов, но попроще. Для этого можно использовать карточку: рассматриваемый вопрос, эвристика, пример использования эвристики для решения этого вопроса. Дальше Ребекка приводит примеры своих записей эвристик.
2) Также можно пойти от противного - найти эвристику, которая противоречит вашей и дальше попробовать подобрать аргументы "за" и "против" для этой эвристики. Интересно, что это напоминает способ развития переговорщиков, когда требуется уметь выступать как за свою позицию, так и за позицию оппонента:)
3) Дальше Ребекка предлагает общаться один на один, обсуждая конкретную тему. Это пересекается с описанным в первом пункте.
4) Фильтровать то, что звучит на конференциях (иронично, что это выступление тоже было на конференции)
5) Записывать то, как вы действительно работаете
В итоге, она предлагает

Record your design values & practices

И в этом контексте вспоминает Майкла Найгарда с его ADR (Architecture Decision Records), которые он предложил использовать для фиксации архитектурных решений в 2011. Кстати, про его книгу "Release it" я писал раньше.
А напоследок Ребекка предлагает следить за тем, что происходит при применении эвристик и использовать это для их тюнинга.

#Management #Software #SoftwareDevelopment #Patterns #Engineering #SelfDevelopment

Patterns of Distributed Systems • Unmesh Joshi & James Lewis • GOTO 2024

Крутое интервью Unmesh Joshi, автора книги "Patterns of Distributed Systems". Расшифровка доступна здесь. Общение состоит из следующих моментов
- Unraveling the Foundations: A Patterns-Based Exploration
Автор книги рассказывает про свой путь как инженера и как он дошел до жизни такой, что написал книгу про паттерны распределенных систем. Мне особенно понравилось как Unmesh рассказывает про изучение реальных распределенных систем (Akka, Kafka, Cassandra, ...), в которых автор находил практические реализации тех концепций, что обычно описаны в whitepapers. Например, в интервью обсуждается часы Лампорта и whitepapers Барбары Лисков (ее принцип отвечает за букву L в акрониме SOLID). В общем, я бы сам с удовольствием поковырялся в реальных технологиях и попробовал сравнить как теоретические концепции реализуются на практике в разных системах и на какие trade-offs идут авторы этих систем
- Should Every Software Developer Should Understand Distributed Systems?
В общем, ответ да:) Но точка зрения зависит от контекста. Условные микросервисы - это тоже распределенная система. Но фокус автора книги был на данных и поддержании их консистентности на многих серверах и он фокусировался на работе систем аля Kafka, Cassandra, Amazon S3, Cosmos DB.
- Comparing Patterns: Raft and Paxos
Здесь ребята обсуждают модели консенсуса - они говорят про
1) Paxos, который предложил уже упоминавшийся Лампорт
2) Raft, одним из соавторов которого был Джон Остерхут, чью книгу "A Philosophy of Software Design" я уже рассказывал в постах: 1 и 2
Тут авторы вспоминают про CAP теорему (я про нее рассказывал), не вспоминают про ее расшширение в виде PACELC (я про нее рассказывал), вспоминают Jepsen с его тестированием гарантий производителей баз данных и проверкой их соответстия моделям консистентности (про них я тоже рассказывал). В обсуждении они говорят про время и вспоминают про TrueTime от Google и гибридные часы в MongoDB, YugabyteDB и CockroachDB.
- Why Are Patterns Useful?
Пользу от паттернов лучше описать словами автора книги

One of the goals for these patterns work as well is that someone reading this material should be able to navigate open-source code bases. And I think navigating, I mean, following open-source products and going through their code bases, trying out, maybe isolating some pieces of it and playing with it, I think that's a great way to learn about distribution. I mean, particularly topics like distributed systems, it's a great way to learn because if you go down the route of theoretical understanding, I mean, there are a lot of nice books, I would say, but you might get lost. So I think it helps a lot to remain closer to code while you are learning stuff.

- Conclusion
Напоследок ребята подводят итоги и James пытается выяснить творческие планы у Unmesh, который планирует продолжать работу над паттернами, а также начать проводить воркшопы на эти темы. Думаю, что я бы на такой воркшоп бы записался:) Ну и обязательно прочту эту книгу - автор мне ее продал в этом интервью.

#Software #Architecture #DistributedSystems #SystemDesign #Patterns #Engineering

Intentional Code - Minimalism in a World of Dogmatic Design - David Whitney - NDC Porto 2023

Занимательное выступление David Whitney, head of architecture в компании New Day, на тему дизайна и проектирования софта, в котором прикольные иллюстрации и интересные мысли, которые можно обобщить до следующего
- Шаблоны проектирования (design patterns), бум которых начался с книги "Design Patterns" от банды четырех (Gang of Four). Конкретно в этой книге шаблоны были разложены на категории creational, structural, behavioral и каждый шаблон описывал типовое решение стандартной проблемы, с которыми часто сталкивались авторы книги. Но это не было призывом к стандартизации всего и вся. Скорее это был общий язык и набор идиом программирования, которые могут быть полезны
- На книгу тему паттернов проектирования в IT большое влияние оказал Кристофер Александер, настоящий архитектор от строительства, а не из IT, который написал знаковые книги "Notes on the Synthesis of Form" и "A Pattern Language: Towns, Buildings, Construction" (стоит у меня на полке и ждет своего часа)
- Виды архитектур: hexagonal architecture (port& adapters), clean architecture, 12 factor app. Автор обсуждает эти подходы, а потом говорит, что в разработке софта есть есть не только шаблоны и виды архитектур
- Давид вспоминает книгу Кнута "Literate programming" ("Грамотное программирование"), где программа фактически пишется на естественном языке, а инструкции входит в неё в форме макроподстановок и кода на языках программирования. Эту концепцию предложил Кнут в 1981 году и использовал при создании TeX. В этой концепции подчеркивается важность формы, потока и ритма кода, а также его смысла и цели существования. Причем код должен быть написан с уважением к читателю:)
- Сложность софта - многие программы чрезмерно сложны, потому что они не формируют правильные абстракции для читателей и им легко потеряться в инфраструктурных моментах и схеме организации кода. Автор выдвигает такой тезис

The complexity of your app should be at most as complex as the problem space it inhabits, and no greater

- Эти подходы к управлению сложностью стоит использовать при дизайне своего приложения и проектировании качественных API
- Автор вспоминает "Чистый код" ("Clean code") дядюшки Боба и говорит, что много лет назад - это была полезная и прорывная книга, но с тех пор она устарела, как устарел и догматичный подход Роберта Мартина, который фиксирует количество строк в функции. Честно говоря, я согласен с такой оценкой книг Роберта Мартина:)
- Дальше автор вспоминает крутую книгу "A philosophy of software design" Джона Остерхута и дальше идет по концепциям из нее. Это крутая книга, которую мы разбирали в рамках клуба Code of Architecture и которую я очень рекомендую к прочтению. И вот какие концепции из этой книги автор освещает
-- Сложность софта может иметь накопительный эффект - маленькие уступки на которые мы идем при написании кода приводят к большому техдолгу
-- Shallow и deep modules - если мы используем абстракции, то они должны быть глубокими и скрывать сложность, а не поверхностными, которые с этим никак не помогают
-- Разработка софта - это компромиссы, что зависят от контекста
-- Проектировать софт надо так, чтобы он был готов к изменениям в будущем

В принципе, в выступлении есть еще много умных мыслей, так что я рекомендую посмотреть его в оригинале:)

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Patterns

Морфология Волшебной Сказки (Рубрика #Writing)

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

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

Дальше автор предлагает пойти не от сюжетов и мотивов, а от их строения и составляющих. Такой подход оказывается чудо как хорош и дальше его продолжают применять в других работах, навроде, "Тысячеликого героя" Джозефа Кэпмбелла (у меня уже был пост про эту книгу).
Сама книга достаточно лаконичная, так как автор уносит в приложения и отдельные работы большую часть проведенного анализа сказок, а в книге делится только основами своей теории и выводами. В итоге, книга состоит из 9 частей
1. К истории вопроса - глава, где автор рассматривает предыдущие подходы к снаряду
2. Метод и материал - здесь автор очерчивает то, что он называет волшебными сказками, которые он и анализирует в своем труде. Дальше показывает, что не важно какие именно персонажи есть в сказке - важно, что они делают и какие функции выполняют. Причем функция - это та поступки персонажа, которые значимы с точки зрения сюжета. А потом следует основные выводы: число функций в известных волшебных сказках ограничено, а мало того они еще и всегда идут в одинаковой последовательности. Поэтому мы получаем неожиданный результат: все волшебные сказки однотипны по своему строению. Интересно, что дальше в книге автор связывает волшебные сказки с мифами и религией.
3. Функции действущих лиц - основная часть работы, которая описывает 31 функцию, в которой у нас участвует герой, жертва, антагонист, даритель, помощники, ложный герой, ... В общем, эту часть интересно читать и видеть как разное поведение можно свести к общим функциям
4. Ассимиляции. Случаи двойного морфологического значения одной функции - здесь автор показывает как некоторые функции в процессе эволюции сказки сливаются воедино, например, есть отдельные функции в виде задачи и боя. Условно бой с драконом или решение сложного квеста царевны, но если царевна задаст задачку сразить дракона, то у нас тут налицо объединение функций:)
5. Некоторые другие элементы сказки - здесь разбираются связки разных функций, утроения (часто встречающиеся в сказках) и мотивироки поступков персонажей
6. Распределение функциий по действующим лицам - здесь автор показывает какие действия могут совершать разные типы персонажей
7. Способы включения в ход действия новых лиц - тут рассматриваются как эти типы персонажей подключаются к сюжету
8. Об аттрибутах действующих лиц и их значении - здесь автор рассказывает про совокупность внешних качеств персонажей и как они придают сказкам красоту и обаяние. Разбирается пример с Бабой-Ягой и ее избушкой, Иван-царевич, волшебные кони, прекрасные царевны.
9. Сказка как целое - а здесь автор берет свой инструментарий и разбирает несколько сказок, показывая как они раскладываются на функции и у нас получаются аля предложения, которые описывают сказку структурно, а дальше эту структуру сказок можно использовать для их классификации.

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

#Writing #Patterns #History

Better Data Visualizations: A Guide for Scholars, Researchers, and Wonks - Part II (Рубрика #Data)

Продолжая первый пост про эту крутую книгу расскажу про две оставшиеся главу из первой части про основные принципы визуализации

Вторая глава содержит пять советов для улучшения визуализаций
1) Show the data - для того, чтобы аудитория лучше поймала смысл визуализации нам надо показать данные, не обязательно показывать все данные, но те данные, что подсвечивают ваше сообщение должны быть на визуализации
2) Reduce the clutter - визуализация должна содержать только необходимые элементы, остальные нужно убрать, чтобы не отвлекать внимание. Условно, редко когда полезны лишние элементы оформления или 3D версии графиков, даже если в Excel они есть
3) Integrate the graphic and text - автор дает сразу несколько советов
- Лучше убрать отдельную легенду и интегрировать ее прямо в график - но на практике часто и легенду убирают и в графике не дают никаких подсказок как его читать
- Написать заголовок к визуализации, который напоминает газетный и прямо говорит об основной мысли визуализации
- Добавить объясняющие элементы в ключевые места визуализации (например, комменты поверх пиков и провалов в обычном линейном графике)
4) Avoid the spaghetti chart - даже если информации много, то не надо вываливать ее на одну визуализацию. Можно сделать несколько отдельных визуализаций, которые подсвечивают вопрос с разных сторон. Но если мы так делаем, то нам надо сделать визуализации похожими, чтобы в них легко было ориентироваться
5) Start with gray - автор предлагает стартовать с серого варианта графика, а цвета добавлять потом для выделения основных моментов
Тут же автор говорит про типы данных: качественные и количественные, где есть дискретные и непрерывные, которые могут быть интервальными или поддерживать отношения. Понимание типа данных очень важно для правильной визуализации.

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

Let you audience's needs drive your data visualization choices

Дальше автор говорит, что форма может быть статическая и интерактивная, а функция объяснительная и исследовательская. Книга больше про статические и объяснительные визуализации, но и другие типы могут быть эффективны для своих целей. Например, раньше (в 1997 году) существовала мантра работы с визуализациями вида

Overview first, zoom and filter, then details-on-demand

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

Продолжение обзора книги в следующих постах.

P.S.
Раньше я уже писал на тему визуализаций:
- Книга "Visual Meetings" про использование визуала для проведения эффективных встреч
- Доклад Brendan Gregg "Visualizing Performance" про визуализацию производительности софта (знаменитые flame charts)
- Книга "Visualizing Change: A data-driven snapshot of our world" с крутыми инфографиками для получения вдохновения
- Книга "MBA в картинках" с интересными визуализациями стандартных менеджерских тем
- Книга "Technology Strategy Patterns" и конкретно часть "Communicating the Strategy" про донесение сложных идей о стратегии до топ-менеджеров

Ну и научно популярные книги по статистике (в более научных книгах по статистике больше все-таки не про визуализацию, а про математику)
- Статистика в комиксах (Inroducing Statistics. A Graphic Guide)
- Статистика. Краткий курс в комиксах (The cartoon guide to statistics)
- Статистика и котики
- Занимательная статистика. Манга (The Manga Guide to Statistics)

#Data #Visualization #Patterns #Leadership

Understanding Distributed Architectures - The Patterns Approach (Рубрика #Architecture)

Недавно на конференции YOW! 2024 выступил Unmesh Joshi, известный эксперт в области распределённых систем, который является Principal Consultant в ThoughtWorks с более чем 20-летним опытом работы в индустрии. Это выступление является кратким изложением его книги "Patterns of Distributed Systems", изданной в 2023 году в серии Мартина Фаулера (на сайте Мартина есть краткая версия каталога паттернов из этой книги). Понятно, что в 35 минутном выступлении рассказать все 30 паттернов из книги он не смог, но вот вот какие темы у него раскрыть получилось
- Введение в распределённые системы - современные системы включают облачные сервисы (cloud services), Kafka, Kubernetes и многие другие распределённые технологии.
- Самоподобие шаблонов - паттерны (patterns) применимы на разных уровнях абстракции и часто демонстрируют свойства самоподобия (self-similarity). Мне это напомнило фракталы:)
- Изучение открытого кода - для выявления шаблонов Unmesh использует "правило трёх реализаций", анализируя open source проекты распределенных систем (Kafka, K8s, Cassandra, ...)
- Каталог из 30 шаблонов - созданный автором каталог шаблонов помогает понять внутреннее устройство распределённых систем, с примерами из реальных продуктов.
- "Симпатия к платформе" - концепция, аналогичная "механической симпатии" (mechanical sympathy) в автогонках, помогающая эффективно использовать системы.

Mechanical sympathy is when you use a tool or system with an understanding of how it operates best. You don't have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy. Jackie Stewart, racing driver.

- Важность практического опыта - реальный код устраняет двусмысленность и превращает абстрактные концепции в конкретные решения. У автора на Github есть репозитории с примерами распределенных систем для оркестрации контейнеров (аля K8s), messaging system (аля Kafka), nosql database (аля Cassandra)
- Структурирование через шаблоны - паттерны помогают организовать информацию и сделать код более понятным, устраняя неясности в документации. Я бы добавил, что они позволяют использовать инженерам общий язык при проектировании сложных систем
- Архитектура как последовательность паттернов - знание шаблонов упрощает понимание сложных архитектур, а также проектирование собственных систем
- Согласованное ядро и управление метаданными - пример паттерна, где небольшой кластер с высокой степенью согласованности (high consistency) управляет метаданными (metadata), что позволяет основному кластеру масштабироваться до тысяч узлов (nodes). По-факту, это стандартная концепция с разделением control plane и data plane.
- Применение шаблонов в реальных системах - у автора есть демонстрация реализации паттернов на примере мнииатюрных версий Kubernetes и Kafka для обучения (можно поискать на Github аккаунте автора, который я приводил выше)

Ну и финальная мысль выступления в том, что эти шаблоны помогают уменьшить случайную сложность (accidental complexity) и прояснить существенную сложность (essential complexity) распределённых систем (distributed systems), что помогает разобраться с таким сложной темой:)

#Software #Architecture #DistributedSystems #SystemDesign #Patterns #Sofware

Balancing Coupling in Software Design - GoTo Book Club 2025

В недавнем интервью для GOTO 2025 Влад Хононов представил свою новую книгу "Balancing Coupling in Software Design" в беседе с Шином Брисалсом. Про книги и выступления Влада я уже как-то рассказывал раньше
- Про его книгу "Learning DDD", на которую я написал 4 кратких обзора: общий обзор DDD, DDD и микросервисы, DDD и event-driven architecture, DDD и data mesh
- Про его выступление "Сложность и модулярность две стороны одной медали" на ArchDays с частью истории про coupling еще до публикации книги (1 и 2)
А вот интервьюера я видел в первый раз, хотя Шин Брисалс тоже автор книги "Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions" (O'Reilly, 2024), который специализируется на помощи командам в проектировании, создании и эксплуатации устойчивых serverless-решений

Основными темами интервью были
- История исследования coupling в системах - здесь Влад рассказывает, как неудачный проект с микросервисами подтолкнул его к глубокому изучению принципов coupling в архитектуре ПО
- Вневременная природа проблем проектирования - несмотря на эволюцию технологий, базовые принципы проектирования и управления связями остаются неизменными на протяжении десятилетий. Влад вдохновлялся книгами 70-х годов
- Три измерения связей: интеграционная сила (knowledge sharing), дистанция и волатильность - фундаментальная модель для оценки связей между компонентами. Ниже представлены основные идеи об этих трех измерениях, хотя собеседники их прямо отдельно не проговаривали
-- Оценка силы интеграции между компонентами является ключевой, начиная от интрузивной связи (высокий обмен знаниями) до контрактной связи (низкий обмен знаниями).
-- Когда физическое расстояние между компонентами увеличивается (например, переход к микросервисам), связь должна быть сбалансирована за счет сокращения общих знаний (например, с четкими контрактами API и отсутствием прямого доступа к данным).
-- Прогнозирование и управление изменчивостью, т. е. скоростью изменений, также имеет решающее значение при проектировании для соответствующего уровня связи. Если один компонент, например устаревшая система, не должен меняться, то высокая сила интеграции или большое расстояние не являются проблемой.
- Декомпозиция проблем и оценка сложности - подходы к разбиению сложных задач и объективной оценке их сложности с учетом неопределенности
- Локальная vs глобальная сложность - как оптимизация локальной сложности отдельных компонентов может привести к увеличению глобальной сложности системы
- Модульность как противовес сложности - модульность является ключом к созданию масштабируемых и поддерживаемых систем
- Границы знаний и абстракции - как правильные абстракции создают эффективные границы знаний между компонентами
- Креативный подход к техническому писательству - использование поэзии в технической книге для лучшего донесения сложных концепций (здесь Влад рассказывает как genAI помогал ему писать стихи для этой книги)

Если обобщать, то эта книга получилась не такой легкой как "Learning DDD", но она все равно очень полезна для всех, кто стремится создавать гибкие, масштабируемые и поддерживаемые программные системы через правильное управление связями между компонентами.

#Software #Architecture #DistributedSystems #SystemDesign #Patterns #Sofware #Metrics #Management

Modern Architecture 101 for New Engineers & Forgetful Experts - NDC Copenhagen 2025 (Рубрика #Architecture)

Отличное выступление Jerry Nixon, product manager из команд SQL Server и Data API Builder, в котором он говорит, что архитектура - это не про "best practices", а про контекстные решения и смелость говорить "нет". Фактически, Никсон разрушает мифы и дальше показывает как строить архитектуру под любой масштаб с учетом вашего контекста. А начинает он с провокации, говоря, что термин "best practice" используют как оправдание отсутствия аргументов. Единственная настоящая best practice - не использовать SQL injection. Все остальное зависит от:
- Политики и бюджета компании
- Уровня команды (джуниоры vs эксперты)
- Наследия систем и ограничений от объединения разных систем
- Возможности "платить за ошибки" (Twitter может себе позволить глупости, а вы - нет)
Дальше он показывает "годовые кольца" технологий: spaghetti code 90-х, трехуровневые приложения 2000-х и микросервисы 2010-х, а дальше заключает, что все это работает до сих пор. В итоге, architecture shaming - это просто неуважение к контексту, в котором были приняты прошлые архитектурные решения.

По Никсону роль архитектора быть хранителем простоты. Ведь архитектор отвечает за самые дорогие решения, которые нельзя отложить. Это не тот, кто рисует схемы в начале проекта, а тот, кто постоянно решает, что оставить за бортом. Главная задача - не добавлять компоненты, а защищать систему от лишнего - это очень похоже на тезис Антуана де Сент-Экзюпери

Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать

После этого спикер начинает показывать как можно начинать проектировать решение с базы и постепенно наращивать сложность по мере появления доп требований
- Client → Database
- Client → API → Database (добавили интерфейс)
- Write API → Primary DB (синхронизация через логи) и Read API → Read replica. Логика в том, что вы масштабируете запись и чтение независимо за счет простого изменения connection string, а также за счет eventual consistency (и вам сразу становитсья важно понимать модели консистентности)
- Дальше появляется API Manager (APIM) / Gateway для управления API, версионирования, балансировки нагрузки, постепенной раскатки и a/b тестов
- Дальше появляется история про мониторинг (Никсон советует OpenTelemetry), кеши и service bus
- Ну и вообще асинхронность - это способ работы на масштабе: CQRS (Command Query Responsibility Segregation), Queue для работы со спайками нагрузки
- И так далее

В общем, выступление очень интересное. Основные мысли примерно такие
- Все компромиссы исходят из реальности, а не идеологии
- Архитектор - это тот, кого винят. Ваши решения будут судить через 5 лет, когда вы уже покинете компанию
- Сложность должна оправдываться. Каждый добавленный компонент (service bus, cache, gateway) - это еще одна система, за которую вы отвечаете.

Ну и напоследок тезис от автора, что меня сначала повеселил, а потом заставил задуматься

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

#Architecture #DistributedSystems #Management #Software #Leadership #Patterns #SystemDesign