Пять рекомендаций, как правильно думать об ИТ-архитектуре

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

Например, заканчиваю сейчас курс по распределённым данным (когда в обработке данных участвует несколько машин) — темка сегодня крайне востребована, потому что практически в любом highload-проекте возникают проблемы с отказоустойчивостью, масштабируемостью, временем отклика... А главное, тренд data-driven сегодня стратегический топ.

Так вот, даже в такой довольно узкой, хоть и must have конечно теме (по сути, это всё про репликацию и секционирование) насчитывается уже под сотню типовых проблем, и в любом решении находятся свои серьёзные минусы, и в длинных причинно-следственых цепочках постоянно возникают замкнутые циклы. Хвост вытащил — клюв увяз, и наоборот.

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

Пока вы просто программист, со временем вырабатываете уникальное мастерство гугления типичных проблем :) Но для архитекторов (подразумеваю далее и проектировщиков, хотя это не одно и тоже) совершенно не так. Тут имеется конечно некоторое множество best practices, но специфика архитекторства такова, что на этом уровне трудности обычно совершенно уникальны — очень сильно связаны с конкретной экосистемой эксплуатации, с конкретной предметной областью, с конкретными условиями и обстоятельствами в конкретной организации. Какова вероятность, что кто-то столкнулся именно с таким сценарием, и описал его в своём блоге или на StackOverflow? Практически нулевая.

=

Ещё больше года назад начал регулярно выискивать и изучать материалы, блоги, книги по правильному проектированию, по архитектурам, и вот оказалось, что их крайне мало, книги или даже посты выходят совсем редко, да и качество их слабенькое подчас. При том, что по технологиям фреймворкам API самых разных материалов океан!

Писал на днях об этом в тележке:

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

Потому что внутри такой ложной реальности, ложной парадигмы любые знания фактически не имеют никакой ценности, их КПД крайне невысокий. От того, что вы прочтёте сотни книг по технологиям, фреймворкам и императивному программированию, не станете в информатике умнее. А вот даже всего от двух-трёх книг по профильной математике, по математической логике, по теории типов — очень даже".

https://t.me/lambda_brain/211

Сделал эту тему (проектирование сложных программных систем с акцентом на хороших абстракциях + немного сопутствующие архитектурно-технические темы) ключевым стратегическим направлением в моей Школе. Понемногу даже в курсы с нуля добавляю соответствующие моменты, а для тех кто Python выбрал, добавил новый "секретный" курс перед алгоритмами.

=

Безусловно, многие в ИТ (архитекторы так наверняка) задавались вопросом, почему же так мало хороших книг по этой теме в сравнении с техническими вопросами. Сермяга в том, что архитекторы редко сталкиваются с обычными "типовыми" проблемами, им постоянно приходится сражаться с необычной сложностью, принимать нечёткие решения в новых ситуациях. Для архитекторов почти каждая проблема — это личный вызов. Потому что реально во многих случаях архитектурная проблема новая не только для конкретной организации, но и для всего мира. Для таких проблем по определению не существует ни книг, ни блогов, ни обсуждений!

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

Правильно — наименее худшая архитектура.

"возьмите лучших из худших" (с)

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

Как именно это делать, будет со временем (возможно, зимой) отдельный курс Ясная архитектура (введение в ЯА кстати у меня уже есть): как быть, когда в проекте постоянно сталкиваешься с трудными проблемами, с которыми и в прямом, и в переносном смысле никто пока не сталкивался раньше, поэтому и нагуглить нечего. Когда принимать множество системных и технологических решений с долгосрочными последствиями, когда всё это вдобавок перемешано с личностными разборками и корпоративной конкуренцией.

Как говорят, "архитектура программной системы — это то, что потом очень трудно изменить".

:)

=

Но начинать всегда надо с того, чтобы организовать и затем постоянно поддерживать понятное и прозрачное текстовое описание всего проекта, всей его архитектуры. Пост был об этом:

https://vk.com/wall-152484379_3422

Как лучше, как технологичнее? Вот например очень хорошее решение:

https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions

Architecture Decision Record (ADR) — текстовый файл (возможно, в markdowm), компактно описывающий одно конкретное архитектурно значимое решение; одна, максимум две странички текста.

Сам файл разбит на такие секции:

- главная идея (одна компактная фраза);

- короткое (1-2 предложение) описание проблемы, и список альтернативных решений;

- выбранное архитектурное решение — достаточно подробное (одна страница, максимум две) описание решение, и детальные аргументы в его пользу;

- cстатус решения: "предложено" (пока в обсуждении), "принято" (согласовано со всеми заинтересованными сторонами), "устаревшее" или "заменённое" (со ссылкой на ADR-замену);

- последствия: любые позитивные и негативные последствия выбранного решения, а также компромиссы, на которые пришлось пойти.

Как организовать организационно-техническое сопровождение набора таких ADR, описано по ссылке выше.

=

Ok, ну вот архитектура спроектирована, все согласились, но как архитектору быть убеждённым, что разработчики действительно придерживаются всех этих ADR? Как вообще гарантировать, что выбранные принципы проектирования воплотятся в реальности?

Лет 20 назад эта важнейшая проблема породила концепцию DevOps, что привело к автоматизации многих проектных операций, ранее выполнявшихся вручную. Принцип автоматизации процесса разработки, отслеживание самых разных метрик действительно позволяет командам работать быстрее, поскольку теперь можно не беспокоиться, что что-то внезапно сломается, а об этом они не узнают вовремя. Нет, теперь к DevOps добавились и CI/CD (позволившие избавиться от схемы, когда каждый разработчик неделями трудится в некоторой изоляции от других, на своей ветке :) а затем "в конце спринта", в пятницу, все пытаются интегрировать свой код в мастере, и начинается полный трэш), и БигДата (анализ множества KPI), и таким образом, автоматизация и обратная связь реального времени (near real time, тоже хорошо) стали сегодня основными факторами эффективной разработки.

Понимаю, тема скучная, но хорошему архитектору никуда от неё не деться. В этой теме эволюционный подход единообразен: это автоматизация той любой повторяющейся рутинной работы, которая пока выполняется дорогостоящим специалистом.

Так вот, если архитектор или сеньоры будут регулярно делать обзоры кода миддлов, соответствуют ли они комплекту ADR, или, ещё хуже, начнут проводить регулярные совещания-обсуждения с ревью архитектуры для оценки её состояния, это ведь по сути то же самое, что продолжать вручную запускать виртуалки, когда такую работу уже давно автоматизировали.

Это будет отрывать уйму времени и ресурсов у специалистов, а вдобавок, в условиях нехватки времени, важные детали архитектурной реализации легко можно упустить из-за поверхностных code review.

=

Короче говоря, если вы нацелены в архитекторство, волшебного рецепта не будет, но пять важных рекомендаций, которые переводят проблему поддержания ручного соответствия "неформальная модель архитектуры, существующая в голове архитектора — реализующий её код" в хотя бы минимально автоматизированный и формализованный вид.

1. Начните с ведения ADR.

2. Осознайте всю глубину тезисов

"Данные —это ценная вещь, и они прослужат дольше, чем сами системы."

Тим Бернерс-Ли (отец Интернета).

"Если вы покажете мне код и скроете структуры данных, я ничего не пойму в вашей программе. Однако, если вы покажете мне структуры данных, код скорее всего не понадобится. Он будет очевиден."

Фредерик Брукс "Мифический человекомесяц" 1975

Скоро кстати на эту тему в СильныхИдеях будет материал о ко-рекурсивном проектировании.

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

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

4. Пункты 2-3 больше про проектирование (дизайн верхнего уровня), а в конкретном техническом плане (чистое архитекторство), всё равно, факт, что сегодня все архитектурные парадигмы явно развиваются в тренде data-driven, однако при это какую-то чёткую рекомендацию дать всё равно невозможно. Например, лет 10+ назад превалировала архитектура SOA, сперва event-driven, потом orchestration-driven. И хотя с позиции сегодняшней моды микросервисы + контейнеры + k8s-оркестровка, вроде бы переход к ней от "SOA+оркестровка" выглядит естественным, однако, уверяю, такие прогнозы даже на 3-5 лет вперёд никто из топовых ИТ-консультационных фирм уровня Gartner или Forrester тогда не рисковал давать.

Парадигма микросервисов фактически полностью оказалась внезапной. Причина? об этом весь данный пост: глобальная экосистема разработки программного обеспечения изменяется и развивается постоянно и, главное, хаотично. В частности, из сотен факторов микросервисную моду в значительной степени запустила связка Linux + Puppet / Chef, но что будет дальше в плане технологий, какая комбинация так же мощно выстрелит, непредсказуемо. Очень многое зависит от того, какие потенциально сильные на сегодня технологии реально созреют завтра.

Короче говоря, разрабатывайте архитектуру, исходя прежде всего из модели данных, это не подведёт ни в какой парадигме. Например, современные подходы к проектированию микросервисов весьма чётко следуют философии Domain-Driven Design, и такая важная фишка DDD, как bounded context, уже совершено явно перешла в разряд типично архитектурных (по сути, это и есть абстракция микросервиса).

5. Но как же правильно архитектору думать?

Рекомендовать "изучать" сотни часов видео с конференций вроде www.highload.ru не буду — это совершенно непродуктивная трата времени.

Начните с вдумчивого изучения книги "Эволюционная архитектура. Поддержка непрерывных изменений" (Куа, Парсонс, Форд).

Сильная идея в ней — это функции пригодности (fitness functions). Целевые функции, с помощью которых архитектор объективно оценивает соответствие заданным критериям некоторой характеристики архитектуры (или комбинации характеристик архитектуры). Это по сути первый учебник на современном уровне, где вводится механизм абстракций для контроля за архитектурными характеристиками проекта.

Например, когда архитектор с помощью функции пригодности оценивает эластичность системы (её способность выдержать внезапный наплыв пользователей), он вообще не парится предметной областью. Это может быть сайт банка, онлайн-игра или интернет-магазин. Получается такое осознанное выделение архитектурных абстракций; кто изучал мои материалы "3 способа мыслить о программе" (для проектировщиков), вот для начала применяйте этот принцип также и к ИТ-архитекторству.

Источник: cognitect.com

Комментарии: