Building Evolutionary Architectures — выпуск 2

Глава посвящена управлению архитектурой, и авторы начинают с инструментов: дизайн-принципы, хорошие практики и практики, которых стоит избегать. Красным на схеме подсвечены ручные ревью и комитеты, зелёным — фитнес-функции, которые в автоматическом или полуавтоматическом режиме контролируют выбранные архитектурные характеристики. Ведущие сразу смягчают приговор: авторы признают, что «плохие» практики появились эволюционно — сначала было совсем плохо, потом подтянулись CI и системы контроля версий, и одно плохое место разделилось на несколько менее плохих, которые тоже поддаются автоматизации. Один из участников добавляет сюжет про издания: вводя термин «эволюционная архитектура», авторы первой версии забыли, что governance существовало и до них, а во втором издании закрыли пробел. Его аргумент: ручные способы плохо масштабируются, если катить изменения хочется чуть ли не тысячу раз в день, а фитнес-функция масштабируется, когда она однозначно зелёная или красная и решение по её прогону принимает машина, а не человек.

У другого участника от главы осталось ощущение сплошного регулирования: это подкрутить, то посмотреть, здесь запретить сборку. Но в конце авторы предупреждают: не превращайтесь в жёсткого регулятора и не забирайтесь в башню из слоновой кости подальше от разработчиков — логируйте, смотрите, анализируйте, а потом делайте ревью самих фитнес-функций и отчётов по ним. Выходит гибкий инструмент: что-то жёстко ограничить, где-то просто собирать аналитику и искать места для улучшения. Дальше ведущие размечают маршрут по главе — примеры, разложенные по скоупам кода, приложения и enterprise, метрики, готовые инструменты, отдельная подглава про хаос-инжиниринг, чек-листы и документация. Отсюда и формулировка, которую ведущий приписывает Вове: фитнес-функция ближе к чек-листу, чем к кнуту, которым заставляют придерживаться правил.

На уровне кода авторы снова берут пару afferent и efferent coupling — входящие и исходящие связи, — хотя в соседней книге сами ругали эту терминологию за разницу в одну букву, из-за которой все путают направление. Дальше идут абстрактность, нестабильность и расстояние до главной последовательности, линии нужной пропорции между ними; фундамент этой модели, напоминает участник, заложил ещё Анкл Боб. Перекос в абстракции даёт зону бесполезности, где ради любой мелочи приходится писать гору инфраструктурного кода, перекос в имплементацию — зону боли, где всё ломается от лёгкого касания: по формулам авторов туда попадает код с множеством сложных методов и классов, например ядро фреймворка, предполагает участник. Отдельный экскурс — откуда взялась метафора: на астрономической диаграмме звёзды выстроены по светимости и температуре поверхности, справа сверху гиганты, живущие недолго и заканчивающие сверхновыми, снизу — плотные белые карлики, а на главной последовательности обычные звёзды вроде Солнца. Зоны бесполезности в астрономии нет: именно сверхновые разбрасывают вещество с высокими атомными числами, из которого собран наш шарик.

Вторая метрика — цикломатическая сложность: популярный порог десять, но авторы советуют держаться пятёрки. Один из ведущих вспоминает разработчика, для которого нормой были семьсот строк сишного кода подряд: «зато читаешь в одном месте». Он и сам сопротивлялся метрике на алгоритмах — сложный околоматематический алгоритм, разрубленный на мелкие методы, иногда читается хуже, и авторы, по его словам, дальше говорят то же самое, — а вот перекладывание структур и бизнес-логику с ветвлениями дробить стоит. Полгода назад у него был спор с инженером, оптимизировавшим hitmap в одной российской соцсети: тот утверждал, что композиция на функции и классы в таких задачах не работает, и на предложение «покажи код, я его отрефакторю» прислал функцию на семь тысяч строк с глобальными переменными — ответить оказалось нечего, контролировать цикломатику в таком модуле уже бессмысленно. Другой участник читает сейчас книгу о том, как мы читаем код: чтение занимает около шестидесяти процентов времени, и если ветвления не помещаются в рабочую память, логику алгоритма не отследить.

Из готовых инструментов авторы разбирают ArchUnit и, по ощущению ведущих, откровенно его рекламируют: контроль зависимостей пакетов, правила именования вроде обязательного суффикса Controller, проверка аннотаций — обращаться к менеджеру сущностей можно только внутри транзакционных методов — и классический контроль слоёв в обе стороны. Отсюда шутка, что сейчас все, у кого нет Java, побегут её ставить: инструменты в таких книгах почему-то всегда на Java. Авторы напоминают, что нечто подобное у вас, скорее всего, уже используется: линтеры своего языка с их API для собственных правил и SonarQube, а из специфичного — контроль лицензий у библиотек через Black Duck; статический анализ в современных IDE добавляет уже ведущий. Выше уровня кода готового инструмента нет: сервисы написаны на разных языках, поэтому авторы предлагают двухступенчатую схему — сначала научить всех писать логи о взаимодействии в едином формате, потом анализировать их скриптом на Python или Ruby. Один из ведущих узнаёт в этом внутренний инструмент, куда сливают логи и метрики и пишут по ним совместные запросы.

Другой участник добавляет, что в оркестраторе то же самое решается network policy, а Дима — что фитнес-функции переезжают на уровень платформы разработки, которая прячет сложность за фасадом; важно только, чтобы абстракция не протекала. Из хаос-инжиниринга упоминают армию обезьян Netflix и Chaos Kong, симулирующий отключение целой зоны: благодаря таким сценариям Netflix пережил падение зоны в Amazon. На enterprise-уровне платформы почти не раскрыты, зато назван антипаттерн Frozen Caveman — архитектор, оторвавшийся от деталей и продвигающий практики десятилетней давности, как герой соседней книги, каждый раз спрашивавший, что будет, если мы потеряем Италию. Документацию фитнес-функций авторы предлагают вести в Cucumber, что участникам кажется странным; вспоминают непопулярный подход Кнута, где естественный язык перемешан с кусочками кода, и его современный аналог — Jupyter-ноутбуки. Дима показывает свой инструмент: правило описывается декларативно, с ответственным и проверкой применимости к репозиторию, а контролировать команде чаще нужно не цикломатику, а версию Node и выбор пакетного менеджера. Финальная картинка книги — отбойник на дороге, с которой не надо съезжать.