Получил удовольствие от прочтения книги "Искусственный интеллект в стратегических играх" Илья Шпигорь
https://leanpub.com/ai-in-strategy-games

Архитектура - это как игра в шахматы. Из огромного количества вариантов ходов мы оставляем лишь те, которые приводят нас к цели. Т.е. архитектура, как и шахматы, - это о том, как не надо делать. На эту тему уже были посты:

- https://www.tgoop.com/emacsway_log/1022
- https://www.tgoop.com/emacsway_log/1181
- https://www.tgoop.com/emacsway_log/1285

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

Шахматы - удивительная наука, которая стоит на стыке политики, воинского искусства (все-таки, это модель двух средневековых армий), моделирования, математики, теории игр (стратегические игры), алгоритмов, искусственного интеллекта, планирования, психологии и, кажется, список можно продолжать.

Они развивают стратегическое мышление, тактику, выдержку. Те качества, которые критически необходимы архитектору или управленцу.

А самое главное, они прививают любовь к постоянной борьбе. Делают борьбу постоянным состоянием. А ведь "software design is a constant battle with complexity" -- Eric Evans.

Практически все выдающиеся исторические деятели увлекались шахматами, от Ивана Грозного до современников.

Для меня наличие шахмат среди хобби соискателя - это огромный "зеленый флаг".

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

Коротко о том, чем отличается Event Sourcing от Mutable State Storage. Ну и заодно о том, чем отличается Функциональная Парадигма от Императивной.

В первом варианте ничего не изменяется - есть только append-only event log.

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

Второй вариант является математической свёрткой событий первого варианта. Соответственно, первый вариант позволяет восстановить состояние на любой момент времени.

Первый вариант (Event Sourcing) часто используется совместно со вторым (CQRS Read Model).

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

Иными словами, архитектура - это постоянная борьба, и шахматы в этом вопросе оказываются очень символичными, хорошо развивая необходимые качества архитектора. Представьте, что за белых играет архитектор, а за черных - Product Owner, который постоянно наровит изменить требования и поставить систему под удар новых требований.

Вилка - тактический прием шахмат, который позволяет взять одновременно две фигуры, т.е., говоря символично, позволяет достигнуть одновременно два "требования" Product Owner. Это то, что архитектор постоянно делает с системой.

Иными словами, одно решение (ADR) позволяет удовлетворить одно из двух требований, независимо от того, какое из них окажется верным в результате эмпирической проверяемости. Возможность адаптировать систему под новые требования. Точка расширения системы.

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

С Product Owner, играющим в шахматы, намного легче развивать систему. Фактически он уже владеет основами системного мышления.

В статьях
https://habr.com/ru/company/cian/blog/569940/
и
https://less.works/ru/less/principles/systems-thinking
приводятся примеры радикальных последствий в тех случаях, когда лицо принимающее решение (ЛПР) плохо понимает основы системного мышления и попадает в ловушку ложной коммутативности.

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

[UPDATE]: отдельного внимания заслуживает понятие "развитости фигур". Т.е. при взятии/жертвовании фигуры имеет значение не только вес фигуры, но и то, сколько ходов в эту фигуру уже вложено. Т.е. оценка превосходства по времени и трудоёмкости.

Если кто еще не подписан на канал Андрея Кузнецова - настоятельно рекомендую. Грамотный спец. Не раз обсуждал с ним сложнейшие вопросы по безопасности.

FINDING SOFTWARE BOUNDARIES
FOR FAST FLOW
Team Topologies and Domain-Driven Design

О дихотомии функции и конструкции на примере шахмат.

В шахматах существует такой тактический прием, как связывание:
https://chessrussian.ru/materialy/beginners/svyazka-primenenie-svyazki/

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

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

Связанную фигуру можно так же рассматривать в качестве слоя трансляции - чтобы защитить свою доменную модель (самую дорогую часть ПО), мы создаем слой трансляции под названием Open Host Service:
this approach of inserting a translation layer for each external system avoids corruption of the models with a minimum of cost
http://ddd.fed.wiki.org/view/open-host-service

Т.е. чтобы предотвратить разрушение модели/конструкции. Все как и в шахматном связывании.

Этот тактический прием открывает также понимание еще и такого явления, как Coupling. Мы не можем изменить дислокацию фигуры (интерфейса), потому что она связана.

См. также.

Может кому-нибудь пригодится для реализации критериев выборки (фильтрации) Public-API по Style Guide AIP-160 by Google:
- https://github.com/einride/aip-go
- https://github.com/aip-dev/google.aip.dev/issues/684
- https://github.com/aip-dev/google.aip.dev/issues/738
- https://google.aip.dev/160
- https://github.com/google/cel-spec
Другие варианты смотрите здесь:
- https://dckms.github.io/system-architecture/emacsway/it/self-education/self-education-for-software-engineer.html#api-design

Только что обнаружил, что Greg Young тоже опубликовал 16 ноября пост на шахматную тематику.

[UPDATE]: И, кажется, он это делает систематически. Видимо, не я один заинтересовался шахматами на почве ИТ-архитектуры.

Физические Agile-доски до сих пор активно используются в крупных IT-компаниях, даже в таких, как Thoughtworks. Это никакой не исторический рудимент. Они используются даже для распределенных команд - в удаленном офисе на самом видном месте устанавливается большой монитор, на который проецируется изображение доски с главного офиса.

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

Основное принцип - доска всегда должна быть перед глазами, на самом видном месте. Её функции больше психологические - она создает контекст погружения в обстановку. И помогает в борьбе с Первым Законом Паркинсона, но это уже отдельная тема для обсуждения, - для эффективного её решения нужны две доски на два спринта.

Так вот, к чему это я. Некоторые мои в т.ч. широко известные коллеги используют бумажный ежедневник, чем неоднократно вводили меня в замешательство. Я считал это рудиментарными привычками. Но недавно у меня появилась хорошая перьевая ручка и мне захотелось купить себе бумажный ежедневник. После непродолжительных поисков мой выбор пал на блокнот fineplan формата A6 на кольцах из натуральной кожи коньячного цвета с тиснением под крокодила. Он у меня всегда раскрыт возле монитора и выполняет те же функции, что и физическая Agile-доска, - постоянно визуализирует образное представление моего личного распорядка перед глазами. Эстетичность блокнота и ручки вызывает желание ими пользоваться. За несколько дней заметил существенное улучшение моей личной сконцентрированности и организованности. И понял, что это никакой не исторический рудимент. Теперь я понимаю своих коллег с бумажными ежедневниками.

Хотя от электронных ежедневников я не отказался, и продолжаю пользоваться Open Source приложениями:

https://github.com/orgzly-revived/orgzly-android-revived (как заядлый емаксоид в прошлом)

и

https://github.com/tasks/tasks

Оба приложения доступны на F-Droid.

[UPDATE]: Тут подвернулось под руку еще одно неплохое Open Source приложение:
https://github.com/johannesjo/super-productivity/