Рецензия на книгу написана как задание в стажировке по руководству “Системная инженерия”, раздел 5 “Эволюционная архитектура”
Написаны посты с рецензиями на книги, представленные в текущем разделе. Обращено особое внимание в этих рецензиях на безмасштабность методов, описанных в текущем разделе: насколько они, по вашему мнению, применимы не только к программным приложениям, но к системам самой разной природы, самых разных масштабов, самых разных уровней сложности.
Книга Neal Ford и других Building Evolutionary Architectures является обязательной частью стажировки “Системной инженерии”, на нее отводится целых две недели.
Мне было довольно просто читать книгу, тем более я плюс-минус знаком с программной инженерией.
До этого в руководствах много раз упоминалась роль архитектора, но именно прочтение книги дало понимание, чем он занимается и что это за фитнес-функции такие.
Оказывается основной характеристикой в современной инженерии является evolvability - способности системы со временем развиваться и любую систему стоит проектировать с учетом возможности развития. Далее для оценки вводятся фитнес-функции. Придумать фитнес-функции может быть непросто - надо, чтобы работа над ее оптимизацией давала нужный эффект и направляла архитектуру системы, а с другой стороны, чтобы ее оптимизация не приводили к ухудшению функциональности.
Стало понятно, почему у архитекторов и разработчиков в сути своей производственный конфликт - работа идет над одним и тем же объектом, но предметы интереса в этом объекте разные: архитектор работает над конструктивным разбиением, именно от этого разбиения зависит как система будет развиваться, а разработчик собственно придумывает как именно реализовать нужную функциональность.
В книге рассказано про программную инженерию, в ней работа архитектора оказывается неразрывно связано с качеством кода. Например, оказывается гайдлайны как надо программировать разрабатывают именно архитекторы.
Правильно выбранная фитнес-функция направляет архитектуру систему.
Архитекторы по факту выполняют функцию надзора за разработчикам. В программной инженерии это происходит автоматически через фитнес-функции и тесты этих фитнес-функций. ADR - Architectural Decision Records - служат документацией для разработчиков - почему их решения должны следовать фитнес-функциям.
С точки зрения взгляда на другие системы, не из программной инженерии - работа архитектора начинается с фитнес-функции, которую надо придумать таким образом, чтобы система развивалась.
Интересно, что архитектор он работает не сколько с системой, сколько с разработчиками системы. Т.е. его функция - надзор и направление разработчиков. Но естественно применительно к системе, т.е. это тоже содержательная роль создателя системы.
Рассмотрим например такую необычную систему как меценат-благотворитель, который жертвует на разные проекты. Какие характеристики у него есть - общая сумма пожертвованных средств, количество пожертвований, количество проектов, в которых он поучаствовал. Какую характеристику надо оптимизировать? Цель - чтобы человек продолжал участвовать в благотворительности, в идеале - увеличивал сумму благотворительности, тогда можно считать, что система развивается. У мецената могут быть разные интересы, он жертвует на благотворительность когда проект удовлетворяет его интересам. Эти интересы могут меняться. Если не будет проектов которые удовлетворяют его тем или иным интересам, пожертвования прекратятся. Соответственно, если нам хочется, чтобы меценат продолжал жертвовать хорошо бы выявлять и предлагать ему проекты, соответствующие его интересам. Таким образом естественным образом мы приходим к фитнес-функции: количество проектов из различных областей, на которые пожертвовал благотворитель. Дальше, конечно, нам надо правильным образом нарезать домен на разные области. Терминологию и идею можно и нужно продолжать чистить, тут главное, что архитектурное рассмотрение выявило интересную характеристику, немного другую нежели те которые на первом плане и сразу приходят на ум. Это и правильно - на первом плане функциональные характеристики, а не архитектурные. Архитектор будет присматривать, чтобы кураторы меценатов предлагали им проекты из других областей, не только тех, в которых уже есть заинтересованность. Можно сформировать соответствующие правило для них (аналог ADR).
Другой пример - система “хороший сон”. (В скобках сразу отвечу на возражение, что это не проект рабочего развития. Да, согласен, но проект из рабочего развития был рассмотрен чуть ранее, а еще один пример лишним не будем). Фитнес функции - среднее количество часов сна, равномерность времени отхода ко сну и просыпания (равномерность также можно формализовать математически и точно надо было бы делать, если бы наш проект скажем был бы кольцо типа Oura Ring). Архитектор сна определяет эти фитнес функции. Далее разработчик работает над их достижением. Для этого выделяется конкретное время сна. Причем каждый день, включая выходные это должно быть одно и то же время, иначе не получится достигнуть равномерности! Далее составляется расписание, таким образом, что за час до планируемого отхода ко сну уже не осталось дел. Это надо принять всерьез, автор текста один раз столкнулся с ситуацией, что с одной стороны планируемое отхода ко сну одно, а тренировка его заканчивалось через полчаса после отхода ко сну, т.е. надо было еще доехать до дома и в самом оптимальном раскладе можно было лечь спать только через час. Архитектор должен следить за тем, что его фитнес-функции не остаются на бумаге, а принимаются всерьез разработчиками. ADR тут могут быть такими: “ничего не планировать на время за час до отхода ко сну”, “количество времени сна должно быть всегда достаточным”, “ложить и вставать всегда в одно и то же время включая выходные”.
Ну и третий пример, для того, чтобы выразить безмасштабность идеи. Предположим мы работаем в гос.регуляторе и наша целевая система - финансовая система страны. Есть множество разных показателей, такие как уровень инфляции, ключевая ставка, госдолг и другие. Какие-то показатели мы сами регулируем, такие как ключевая ставка, а на какие-то как уровень инфляции можем влиять лишь опосредованно. Тут тоже можно ставить вопрос о фитнес-функции и от того, какая будет фитнес-функция будет сильно зависеть качество остальных принимаемых решений. Например если будет выбрано решение минимизировать инфляцию любой ценой, то наверное в долгосрочной перспективе это не благоразумно, т.к. пострадают другие показатели.