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

Лет пять назад я обнаружил для себя Чистую архитектуру Дяди Боба и на некоторое время успокоился, пока поток новых источников постепенно не начал менять мое отношение и к этой книге. Но, если вы решили для себя, что Чистая архитектура — это ваш окончательный выбор, то я точно не буду вас отговаривать, потому что, на мой взгляд, это однозначно лучше, чем, наверное, 90% того, что вам встретится на рынке.

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

Раньше мы в 3 частях [1, 2, 3] пробежались по основным идеям архитектуры систем. Поэтому, если вы ищете информацию по System Design, микросервисам и топологии команд, то вам туда. Эта же статья про архитектуру внутри кодовой базы: она посвящена концепциям программирования, влияющим на структуру приложения, поэтому описывает не только архитектурные подходы, но и иные идеи, оставляющие на дизайне свой отпечаток.

Все знают аббревиатуру CI/CD. Continuous Integration and Continuous Delivery - Непрерывная интеграция и Непрерывная поставка. Но едва ли можно найти более неправильно понимаемую нашей индустрией идею, чем непрерывная интеграция. Практика, которая была придумана, чтобы её делали разработчики, почему-то превратилась в объект работы девопсов, хотя к культуре DevOps ну вообще никакого отношения, по идее, иметь не должна.

Так что вот вам статья про то, как так вышло, что сейчас под CI понимают что угодно, кроме того, чем она, на самом деле, является.

Сколько времени нужно, чтобы завязать шнурки? Ну, секунд десять. А чтобы написать инструкцию, как завязывать шнурки?

Вот и в софте у нас самая честная оценка - я не знаю.

А как быть, когда все же надо дать оценку? Чтобы ответить на этот вопрос, подготовил небольшой обзор, в котором мы рассмотрим:

1. Что твердят источники

2. Что творит индустрия

3. Что говорит здравый смысл

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

1. Когда сложившаяся архитектура подлежит масштабным изменениям.

2. Что не менее важно, когда лучше оставить, как есть.

3. Ключевые признаки проблем в архитектуре.

4. Основные способы исправления таких проблем.

Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:

1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.

2. Что маленькие команды работают буквально в разы эффективнее, чем большие.

3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.

Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».

В прошлой части мы разобрали:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

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

1. Как не допустить появления связанной архитектуры и сразу сделать хорошо?

2. Как исправить уже связанную архитектуру?

В этой части постараюсь развернуто ответить именно на первый, оставив второй на десерт.

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

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