Building Evolutionary Architectures — выпуск 5

Третья часть — про импакт: механики дали теоретическую базу, структура — конкретные примеры архитектур, а здесь всё склеивают вместе. Первая глава называется так же, как вся книга, внутри неё есть подраздел «механики», и участники замечают, что фантазия авторов на названия закончилась, а каждая крупная тема начинается с одинакового разгона: раньше железо было дорогим, поэтому решения принимали так, зато теперь посмотрите, какие хорошие микросервисы. Глава открывается сводкой принципов, и самый живой из них — last responsible moment. Один из участников разбирает кейс банка, который делал новый инструмент для работы с контрагентами: кросс-функциональная команда из двух разработчиков, тестировщика, аналитика и безопасника шла недельными итерациями, первую версию собрала на тупейшей HTML-форме и бэкенде на коллекциях Java, данные принимала в Excel и носила контрагентам за обратной связью. Внешнюю базу завели, по прикидке рассказчика, только на седьмой итерации — месяц-полтора спустя; безопасность подключили примерно через два месяца, когда самые сложные гипотезы не опровергли.

Главная методическая претензия к книге: принципы эволюционной архитектуры появляются отдельной главой ближе к концу, тогда как в другой книге по архитектуре, которую участник читал параллельно, шесть принципов лежат на первой странице, и дальше авторы в каждом примере показывают, как ими принимают решения. Связку участники достраивают сами: корни — в теории ограничений, а почти всё вместе — про декаплинг на разных уровнях. Last responsible moment развязывает решения во времени, закон Постела — интерфейсы, тестопригодность — процессы, закон Конвея — команды; из статьи Конвея вспоминают последний абзац, где предлагается вознаграждать руководителей за то, что их организации остаются компактными. Тестопригодность разбирают на фронтенде: у интернет-магазина под сотню внешних скриптов на главной, тесты цепляются за элементы по id, и десяти командам приходится договариваться о префиксах, чтобы идентификаторы не пересекались. Набор свойств красивый, но, по словам участника, напоминает классификацию животных из энциклопедии китайского императора: мышления для принятия решений из него не выстроить.

Ключевую концепцию книги участники формулируют так: код мы научились быстро доводить до продакшена, потом к нему добавилась инфраструктура как код и поехала по тому же пайплайну, а теперь авторы кладут туда третий слой — архитектуру, которая тоже описывается кодом. Как код проверяют юнит-тестами, а инфраструктуру — интеграционными, так архитектуру проверяют архитектурными тестами вроде нагрузочных: остаётся ли она жизнеспособной в интересующих нас пределах. Без этой мысли, считает один из участников, книгу вообще трудно понять. Другой выстраивает ту же линию исторически: agile и экстремальные практики научили постоянно проверять бизнес-логику, devops-трансформация перенесла практики на инфраструктуру, теперь то же самое растягивают на архитектуру. Из мелочей цепляет метрика LCOM, которая всплывает только в конце книги: она показывает сцепленность методов и данных внутри класса, но логических связей не видит, а инструмент к ней на GitHub создан в 2005 году и последний коммит получил лет пять назад.

Список гайдлайнов проходят бегом. «Убрать лишнюю вариативность» иллюстрируют immutable-инфраструктурой: ручные настройки заменяются описанием в коде, и авторы оговаривают, что неизменяемость не спорит с эволюционностью, а убирает случайные различия и ошибки. «Делать решения обратимыми» тянет за собой дикую историю про один и тот же фича-флаг, переиспользованный под разную функциональность, шутку, что попасть на 400 миллионов ещё надо уметь, и письма Джеффа Безоса акционерам: обратимое решение не выносят на комитет, его принимает умный человек на своём уровне. Жертвенная архитектура — термин, который, по словам участника, принёс Мартин Фаулер, — иллюстрируется Twitter: быстро вышли на рынок, потом переписали всё под нагрузку; тут же возникает вопрос, насколько эволюционен подход, где эволюция означает полное переписывание. Внешние библиотеки советуют всегда закрывать собственными интерфейсами, а из версионирования авторы рекомендуют держать не больше двух версий.

Вторая глава — антипаттерны и подводные камни: первое кажется хорошей практикой и подводит позже, второе бьёт сразу. Десятипроцентная ловушка: коробочное решение или язык четвёртого поколения закрывают 80 процентов потребностей легко, 10 процентов хаками, а последние 10 не закрывают вовсе — и заранее никто не скажет, какие именно; участники добавляют, что ловушка не только про функциональность, но и про лицензии и поддержку. Vendor king — когда ядром собственного домена становится вендорская коробка, обмазанная адаптерами; в примерах звучат коробки 1С, CRM и CMS, а финал обычно один: переписывать заново или строить рядом такой же заводик на своих технологиях. Помогает регулярный аудит — закрыть вендорское решение на схеме чёрным квадратом и посмотреть, что сломается. В чистом виде vendor king — бизнес-логика в хранимых процедурах; отдельная тема — импортозамещение, где срок жёстче любого перформанса. В инкрементальных изменениях достаётся единому стеку для всех решений: архитектор из Wunderlist, наоборот, навязывал командам разные технологии, чтобы между решениями не возникало случайных связей.

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