Архитектура и легаси · · обновлено · 5 мин чтения

Как разбирать чужую архитектуру, чтобы не сжечь бюджет на «переписывание с нуля»

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

Текст: Алексей Меркулов

Как разбирать чужую архитектуру, чтобы не сжечь бюджет на «переписывание с нуля»

Когда собственнику или тимлиду приносят «старый портал» и предлагают переписать с нуля, деньги часто уходят ещё до понимания, где система зарабатывает и где горит поддержка. Алексей Меркулов (Fobscraft) разбирает чужую архитектуру так: сначала карта денег, затем поверхность и швы, потом один узкий шаг с измеримым эффектом. Ниже — порядок, который даёт план работ и бюджет, а не спор про стек. Похожий разбор можно заказать через услуги Fobscraft.

Что обычно происходит в первую неделю

Обратите внимание на сцену. На столе — доступ к репозиторию, пара скриншотов админки и фраза: «тут всё плохо, давайте с нуля». Кто-то уже открыл редактор кода. Кто-то рисует схему из двадцати будущих сервисов.

Через месяц выясняется неприятное. Переписали кусок, который почти никто не открывал. А экран заявок, из‑за которого менеджеры сидят до ночи, остался как был. Бюджет ушёл, боль осталась.

Почему так выходит? Потому что «плохо» в коде и «дорого» для бизнеса — разные карты. Редактор показывает структуру файлов. Он не показывает, какой маршрут приносит оплату и какой модуль съедает часы поддержки.

Сначала четыре вопроса про деньги

Заметьте: до любой диаграммы компонентов можно ответить на четыре вещи. Ответы часто дают люди из продаж, поддержки и финансов — не только разработчики.

  • Какие экраны и интерфейсы приносят оплату, лиды или удержание клиентов?
  • Какие куски системы съедают часы команды каждый месяц?
  • Где сбои бьют по договорённому уровню сервиса и по репутации?
  • Что опасно трогать из‑за юридики, внешних интеграций или сезонной выручки?

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

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

Поверхность: что система делает снаружи

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

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

Принцип простой: сначала назовите контуры и их владельцев по смыслу, потом лезьте внутрь модуля. Иначе вы чините «сервис», а ломаете три разных бизнеса в одной кодовой базе.

Швы: где модули склеены

Теперь изменим только фокус. Смотрим на места, где два контура делят одну таблицу, один кэш или один «сервис, который знает всё».

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

Принцип: режем шов, когда он мешает деньгам или скорости нужного контура. Резать «для чистоты» — отдельное решение, и оно обычно дороже, чем кажется в презентации.

Долг тоже имеет цену

После поверхности и швов список «технического долга» обычно раздувается. Обратите внимание: пункты в этом списке стоят по-разному.

Мёртвый код, который никто не вызывает, можно оставить лежать. Долг на платёжном пути, на очереди с деньгами или на форме заявки стоит часов поддержки и потерянных сделок каждый месяц. Путаница возникает, когда оба типа долга кладут в одну корзину «надо бы переписать».

Принцип: дорогим считайте долг, который уже жжёт выручку или поддержку. Остальное — очередь, а не пожар.

Один узкий шаг вместо большого переписывания

Когда карта денег, контуры, швы и дорогой долг собраны, появляется искушение «сделать правильно сразу». Здесь полезно замедлиться.

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

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

Что отдать команде после разбора

Минимальный полезный пакет умещается на трёх артефактах.

  • Схема границ: какие контуры есть и где между ними швы.
  • Таблица «боль → деньги → действие → оценка сейчас / в месяц».
  • Список запретов на ближайший квартал: что сознательно не трогаем.

Если после этого команда может чинить выручку без героизма и без спора «а может всё с нуля» — разбор сработал. Моё участие обычно заканчивается на проектировании и консультациях; дальше считается экономика исполнения.

Что вы теперь можете объяснить

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

Заказ

Нужен разбор или архитектура

Напишите в Telegram или на почту — посчитаем эффект и стоимость. Форм на сайте нет.