В рамках прохождение курса “Системная инженерия” прочитана книга “Эволюционная архитектура.” (272 стр., план 6 часов, факт 9 часов). Книга не очень объёмная, но по сравнению с предыдущей мяса лично для меня в тексте больше. Видимо поэтому настолько растянулось чтение.
Продолжает программистов преследовать наследие неверного понимания. Сначала поняли, что разработка ПО и конвейеры на заводах это разное. Теперь поняли, что архитектура зданий и архитектура ПО тоже про разное. Программная система скорее похожа на живой организм нежели на здание, которое при хорошей архитектуре простоит века в почти неизменном виде. Оказывается ход сбоку из биологии, пришёл не совсем сбоку. Программировали генетические алгоритмы. И там вариант намеренной эволюции выглядит опять как ход с гипотезами. Мы хотим что-то поменять в живой структуре, но хотим smart mutation. Т.е. это тот же самый инкремент. Надо его применять, и хочется быстро проверить, что поменялось то, что нужно на следующей версии. В эволюции следующая версия это следующее поколение. Но в условиях лаборатории берётся какой-то небольшой вид (мушки, мышки) и у них (простите) релизный цикл достаточно короткий. Т.е. новое поколение можно быстро получить с изменёнными свойствами. А дальше нам нужно сделать test этого поколения и он чуть сложнее, чем привычный assert. В каком-то смысле это вариация behaviour testing. Поведение изменилось, потому что изменилась характеристика. И вот для этого теста люди, которые программировали генетические алгоритмы вводят понятие - фитнес функции/функции соответствия/fitness function/fit function.
Как это всё вливается в архитектуру ПО? Классическая архитектура делает то же самое, что делает архитектура здания. Нам в прошлой книжке Фарли рассказывал про “эррозию кода” (эррозия почв). Код портится по временем. Здание со временем ветшает, а архитектура ПО точно так же портится. С самопроизвольным ухудшением кода мы боремся, когда боремся с техдолгом. И есть нюанс. За деревьями не видно леса. За кодом мы следим, за архитектурой нет. Она меняется (нынче) гораздо стремительнее. Скорость же, инкременты, сервисы распадаются на новые. И вот вопрос выживания (и возможности развития) проекта, должен проходить по всем системным уровням (код модулей, код сервиса, архитектура сервиса, архитектура всего программного комплекса, туда же опять команды из людей, отделы из людей, фирма из отделов).
Фитнес функция позволяет проверять (следить/governance), что важная характеристика архитектуры остаётся в заданных пределах. Что нам это даёт? Даёт управляемые инкременты (автоматизация, контроль). Там конечно всё гораздо хуже чем с тестами ПО, готовых фреймворков нет. Да и сама проверка характеристики творческая задача. Нужно придумать какими средствами можно выразить эту фитнес функцию.
Понятие универсальное. Например, фитнес функции можно реализовывать в инженерии предприятий. Потому что получается есть те же предпочитаемые характеристики системы и те же проблемы, связность, разбивка на модули, коммуникации (синхронные/асинхронные). Функция принимает на вход какие-то данные, возможно обрабатывает их и на выходе делает assert (утверждение) в диапазоне.
Примеры метрик:
- онбоардинг (этап) время до первого коммита в проект (день первого коммита минус день приёма на работу),
- время до первой сделанной задачи (задача проверена, изменения слиты в основную ветку),
- время до первой доставки на прод (задача сделана и доехала до пользователей).
И тому подобное. Время вкатывания в домен (делаются задачи своего уровня с небольшой помощью коллег). Время до выхода на базовую продуктивность (делаются задачи своего уровня без необходимой помощи от коллег). И там рисуется какой мы диапазон считаем приемлемым. Типа время до первого коммита 3-5 дней. До закрытия задачи 5-8. Не выполнение такой фитнес функции может подсвечивать разные проблемы в разных местах. Но наверное это базовая фитнес функция, а под ней уже идёт набор более мелких фитнес-функцией (альфы вспоминаем). До первого коммита человек проходит: оформление документов, выдачу техники, выдачу доступов, разворачивание проекта, знакомство с проектом, знакомство с доменом. И всё это можно мерить и/или выбирать методы, инструменты. Непрерывно улучшать.
Поднята проблема ещё одного устаревшего мышления аля “строительство здания” - это эволюционность данных. Т.е. архитектура наших данных в БД. Не смотря на то, что всякие не реляционные модели наплодились и живут. Подход к данным в голове более фундаментальный. Надо правильно сразу планировать как будет выглядеть набор таблиц и структура таблицы, чтобы это соответствовало запросам пользователей. А пользователи что? “Там не знают чего они хочут”. Мы само собой меняем структуру таблиц, но вздохи по поводу “неправильная архитектура” и “не могли заранее подумать” продолжаются. Про эволюцию данных через время придётся книжку читать, проблема достаточно острая и рабочая (Refactoring Databases).
Наконец-то получила объяснения про закон Конвея вместе с обратным маневром по нему. Становится понятнее почему всё так после объяснений про проблемы архитектуры. Кроссфункциональные команды по традиции оказались не тем, чем казались. В максимально полном виде внутри такой команды не только программисты, тестировщик, БА (всё ещё тут у нас аналитики числятся), ПМ (продакт), но и люди, которые везде, где я работала живут в сервисных командах: инженер инфраструктуры (devops), дизайнер. Все оговорки про реальность делаются. Мол пусть devops хотя бы раз в неделю приходит на целый день в конкретную команду и быстренько решает все поступающие вопросы (вариант дежурства). Пусть тестировщик будет на пару команд общий (у нас похожие штуки есть). И все проблемы связанности на примере людей.
Что в тумане будущего? Фитнес-функции на основе ИИ, генеративное тестирование.
В книге много про прикладную архитектурную работу. В очередной раз можно поплакать, что её никто не делает! При этом по ролям, есть такой ход “архитекторы совместно с разработчиками” вот это всё продумывают, организуют слежку. У нас один системный архитектор на весь продукт. И я думаю, что это сомнительное архитектурное решение. Даже не только всмысле не всегда продуктивных конфликтов с разработчиками, сколько это бутылочное горлышко. И есть подозрение, что держать в голове такой большой массив связей не получится. Здесь должна быть оговорка, ни в какой не в голове, экзокортекс! Но про это в книге тоже есть, если архитектор приходит в проект, который уже живёт какое-то время (год+) своей жизнью разгрести там “ком грязи” и хотя бы вывести какие связи уже есть, это целая проблема. Можно в этом болоте и утонуть. Я делаю вывод, что роль должна быть размазана на разработчиков например. Так же как полностью скинуть все задачи по доставке и эксплуатации на инженеров из сервисной команды не получится, должна быть часть экспертизы на стыке так же размазана на команду разработчиков. Чего конечно же разработчики не хотят. Все хотят сидеть внутри своего кружка ответственности. Примерно так же окажется, что отдельных методологов нет. Но кто-то же должен делать методологическую работу…
Перекладывание идей из программной инженерии на какую-то другую инженерию вполне работает. Тестирование контрактов (на стороне потребителя) это ж чеклисты на стыке передачи работ из одного “модуля” (команды) в другой. И там дальше пример с согласованием правок в стостраничном документе (хорошо бы инкрементно, хорошо бы автоматизировать). Но фитнес-функции вполне себе бывают ручные. Т.е. если правки разослать всем (у нас так например комментарии по мере ревью кода приходят всем подписавшимся на почту), какая-то ручная сверка соответствия вполне себе фитнес функция. А не приплетаю ли я теперь новое понятие везде? Да, но с документом какая-то характеристика точно есть (согласованность например), её просто выделить нужно. С чеклистами это стабильность и тестируемость потока работ проходящего через разные станки (людей с копутерами).
P.S.
Животное, изображенное на обложке, — открытый мозговой коралл (Trachyphyllia geoffroyi). Этот коралл с крупными полипами, также известный как складчатый или кратерный, обитает в Индийском океане.
Такие свободноживущие кораллы, выделяющиеся своими характерными складками, яркой окраской и выносливостью, днем питаются за счет продуктов фотосинтеза произрастающих на них зооксантелловых водорослей, а ночью расправляют свои ловчие щупальца в поисках добычи — различных видов планктона и мелкой рыбешки — и отправляют ее в один из своих ртов (у некоторых подобных кораллов два или три рта).
Нормально так у коррала с выживаемостью и эволюцией)