1. Вступление. Про хорошую архитектуру и архитектуру вообще

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

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

Что говорят исследования?

Есть очень известная в узких кругах исследовательская группа DORA, которая год за годом уже более десяти лет последовательно пытается доказать, что технические практики и IT положительно влияют на бизнес.

Им удалось сконструировать метрику технического качества организации IT Performance, которая из года в год стабильно показывает, что отличники в этой метрике имеют в 2 раза большую вероятность превзойти собственные планы по: прибыльности, доли рынка, продуктивности, количеству услуг и товаров, операционной эффективности, удовлетворенности клиентов, качеству услуг и товаров, достижению целей миссии и организации, демонстрации внешним акторам своих результатов.

Список уже длинный и скучный, но, как будто бы этого мало, оказывается, что отличники еще и тратят на 26% меньше времени на исправление косяков, уделяя вместо этого на 44% больше времени новым фичам. Они имеют в 5 раз меньше косячных релизов и восстанавливаются при проблемах в десятки раз быстрее. Сотрудники таких организаций в ~2 раза чаще считают свою компанию хорошим местом для работы и рекомендуют её другим. [1] [2]

Это все впечатляет, конечно, но при чём тут архитектура? Да при том, что из всех технических практик, которые они замеряли, именно слабо-связанная (loosely-coupled) архитектура больше всего, как оказалось, влияет на этот самый IT Performance и, следовательно, на бизнес.

И обратите внимание на слово связанная (coupled), это термин как раз того самого Структурного дизайна, про который, собственно, и пойдет далее речь в статье.

Для дотошных - чуть более детальный разбор выводов.

Если вы не любите душную нудятину (что вы забыли на Хабре?), то смело листайте вниз до следующего заголовка.

Итак, уважаемый читатель, следи за руками, мы вступаем на скользкий путь интерпретации исследований. Приведу ниже конкретную цитату, которую нам надо разобрать по полочкам.

Loosely coupled architectures and teams are the strongest predictor of continuous delivery.

State Of Devops 2017

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

Обратите внимание, на этот самый IT Performance, который, как мы уже выше говорили, очень положительно влияет на бизнес. Эта метрика вытекает из агрегата Continuous Delivery с коэффициентом корреляции 0,5 (средняя сила связи). А самым сильным предиктором Continuous Delivery, в свою очередь, как следует из цитаты выше, является именно Loosely-Coupled Architecture. Отсюда следует, что по цепочке именно архитектура влияет на бизнес больше остальных замеренных технических практик.

Почему больше остальных? Потому что, как можно заметить на иллюстрации, все технические практики мерились не напрямую, а именно через агрегат Continuous Delivery.

Насколько сильна связь архитектуры и всяких там успехов? По иллюстрации видно, что за год до этого самым сильным предиктором Continuous Delivery были автотесты с коэффициентом корреляции почти 0,5 (средняя сила связи). Выходит, что связь архитектуры с Continuous Delivery не ниже, чем средняя. На самом деле, если знать, что за агрегат там под этим IT Performance скрывается, то преимущество архитектуры над автотестами оказывается хоть и неожиданным, но при детальном рассмотрении вполне логичным.

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

Итого: архитектура важнее остальных технических практик и даже влияет на общие успехи компании, хоть все же косвенно и, кажется, совсем не критично. Из-за косячной архитектуры, кажется, очень непросто запороть прям весь бизнес, но, задумайтесь, как она будет характеризовать техдира или архитектора? Ведь именно обеспечение хорошего IT Performance и, как следствие, архитектуры - это их самая главная прямая обязанность.

Как отличить хорошую архитектуру от плохой или что говорят исследования.

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

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

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

• команда может вносить масштабные изменения в своей системе независимо от того, внесли ли изменения в свои системы другие команды;

• команда может выполнить свою работу без коммуникации и координации с людьми вне своей команды;

• команда может протестировать свою систему по требованию без использования единой интеграционной среды;

• команда может релизнуться по требованию вне зависимости от других команд;

• команда может релизнуться в рабочее время без простоя, независимо от других сервисов;

Почему исследование показало именно такой результат? Если любого сеньора или тимлида попросить попытаться обосновать эту идею, то он довольно быстро вспомнит всё:

• Как им надо было сделать фичу, а они месяц ждали, пока другая команда доделает свою часть.

• Как они пришли к соседям, а те сказали, что их просьба - это дурной архитектурный вкус, и вообще у них куча других дел.

• Как они неделю не могли протеститься, потому что общий стенд был не в состоянии.

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

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

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

2. Про структурный дизайн или что пишут в умных книжках

И вот здесь мы и входим в главную тему статьи - в область теории структурного дизайна. Это концепция сформулирована вот уже больше 50 лет назад и с тех пор лежит в основе теории разработки ПО. Тогда авторы задались целью снизить стоимость разработки ПО, предложив очень важные на тот момент идеи. Именно в статье и книге "Структурный дизайн" из далеких 70-х были сформулированы 2 ключевых концепта построения любого ПО: coupling и cohesion. Я специально буду стараться использовать эти термины в оригинале, чтобы ни у кого не было путаницы, потому что на русском у них слишком много вариантов перевода.

Coupling (в вики "зацепление") - это, в оригинале, степень зависимости двух элементов программы (строчек, переменных, функций) между собой. Выражаясь простым языком: если вы потрогали кусочек кода в одном месте, а оно, например, сломало что-то вам в другом, то эта связь и называется coupling. В теории структурного дизайна именно coupling рассматривается, как основной источник стоимости программ. Это очень легко понять, любому, кто работал на проекте со спагетти-кодом. В системах, где зависимости паутиной расползаются по кодовой базе, разобраться, что происходит в коде обычно крайне сложно, а правки приходится делать предельно аккуратно.

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

Если разбросанные по всему коду связи это плохо, то получается, что связанные элементы должны находиться рядом друг с другому, в одном месте, в одном компоненте. Поэтому в пару к этому термину авторы вводят меру того, насколько такие зависимости плотно упакованы в компоненты. Эту меру авторы назвали "Cohesion". Простыми словами, cohesion - это "хороший" coupling, который не выходит за пределы компонента.

В физических терминах cohesion - это плотность coupling-связей. В хорошей кодовой базе связи не ровным слоем размазаны по коду, а собраны в плотные пучки с небольшим количеством зависимостей между собой.

Считается, что coupling и cohesion в рамках одной кодовой базы обратно связаны между собой: высокий coupling в системе будет означать слабый cohesion. И если рассматривать реальные связи между большими компонентами системы (классами, модулями и даже сервисами), то это правило оказывается вполне корректным: чем выше плотность связей внутри этих компонентов, тем обычно меньше связей между ними.

Выходит, что в теории структурного дизайна идеальная система построена из слабо связанных между собой, но плотно упакованных внутри компонентов. В таком контексте coupling - это уже не плохо и не хорошо. Это просто неизбежное свойство кода.

Надо учитывать и то, что механизмы снижения coupling-связанности имеют свою цену. Как правило, это повышение сложности системы. Примеры таких механизмов: полиморфизм и построенные на его основе те самые Design Patterns, а также событийные шаблоны взаимодействия.

В то же время основным механизмом повышения плотности связей (cohesion) будет рефакторинг и реструктуризация системы. Такие подходы снижают сложность кодовой базы, но, разумеется, требуют инвестиций, которые потом, конечно же, окупятся с лихвой.

Предисловие к следующей части

Таким образом, исследователи смогли подтвердить теорию структурного дизайна, доказав, что ключевым свойством хорошей архитектуры является низкая зависимость команд друг от друга. Обратите внимание, в данном контексте низкая зависимость команд = низкая зависимость компонентов. Кроме ситуаций, где за один компонент отвечает больше одной команды.

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

Меня зовут Саша Раковский. Работаю техлидом в расчетном центре одного из крупнейших банков РФ, где ежедневно проводятся миллионы платежей, а ошибка может стоить банку очень дорого. Законченный фанат экстремального программирования, а значит и DDD, TDD, и вот этого всего. Штуки редкие, крутые, так мало кто умеет, для этого я здесь - делюсь опытом. Если стало интересно, добро пожаловать в мой блог.