Дмитрий Голицын – Непрерывный рефакторинг коммерческого программного обеспечения (страница 2)

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

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

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

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

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

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

Поэтому хороший архитектор обязан мыслить не только сущностями кода, но и экономикой изменений. Решение правильно не тогда, когда его приятно защищать на техническом митапе, а тогда, когда оно выдерживает встречу с P&L, операционными ограничениями и реальным горизонтом планирования компании.

Глава 3. Core и generic domain

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

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

Платежный контур, скоринг, ценообразование, механизм назначения исполнителя, алгоритм поиска в маркетплейсе, расчет тарифа, антифрод — типичные кандидаты в core domain. Фильтр в административной панели, экспорт в редкий формат, страница внутренней статистики для разового аудита, второстепенная CRM-интеграция — типичные кандидаты в generic или supporting domain. Ошибка в первом случае может немедленно ударить по деньгам. Во втором случае неприятность реальна, но ее масштаб иной.

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.