Пролог. Наслаждаясь рассветом, думай о закате

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

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

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

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

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

Из этого вытекает еще одна неприятная, но полезная истина: непрерывная разработка в коммерческом ПО почти всегда является непрерывным рефакторингом. Даже когда команда думает, что просто «пилит фичи», она на самом деле меняет структуру системы, переопределяет границы, стабилизирует одни абстракции и убивает другие. Продукт растет не добавлением кирпичиков в готовый дом, а постоянной перестройкой квартала, в котором уже живут люди.

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

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

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

Часть I. Коммерческая реальность ПО

Глава 1. ПО, которое можно убить

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

Я называю владельцем системы не того, кто ее придумал, и не того, кто любит ее больше всех. Владелец — это тот, кто может принять решение о ее прекращении, замене, продаже, радикальном сокращении или развороте в другую сторону. В продуктовой компании это может быть основатель, CEO, CPO или совет директоров. В энтерпрайзе — бизнес-подразделение, которое распоряжается бюджетом и отвечает за результат. У этого человека или группы людей почти никогда не болит сердце из-за архитектурной красоты. Их интересует другое: достигает ли система целей, ради которых ее содержат.

Это определение полезно своей жесткостью. Оно сразу возвращает программное обеспечение из сферы эстетики в сферу управления активами. Код не является самостоятельной ценностью. Он — дорогой, капризный, изменчивый инструмент. Его пишут ради эффекта: выручки, сокращения издержек, ускорения операций, снижения ошибок, повышения удержания, доступа к новому рынку. Иногда ради возможности вообще существовать как бизнес. Но никогда — ради самого кода, если только компания не продает инструменты для написания кода.

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

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

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

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

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

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

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

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

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