Код помнит все версии бизнеса

ТЕХНИЧЕСКИЙ ДОЛГ НЕ ВСЕГДА ИСТОРИЯ О ПЛОХИХ РАЗРАБОТЧИКАХ

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

Мне никогда не нравилось такое объяснение.

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

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

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

Именно эта мысль для меня принципиальна.

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

Продукт продолжает развиваться.

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

ХОРОШИЙ РАЗРАБОТЧИК НЕ МОЖЕТ ПРОСТО УДАЛИТЬ ТО, ЧТО КАЖЕТСЯ ЛИШНИМ

Именно здесь и начинается настоящая стоимость изменений.

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

То, что я не понимаю назначение этого кода, ещё не означает, что он больше не нужен.

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

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

И очень часто ответ звучит примерно так: «Мне кажется, это уже не нужно.»

Кажется. Именно в этом проблема.

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

В программной инженерии уже давно изучают проблему program comprehension, понимания существующих систем, потому что именно оно занимает значительную часть времени при развитии программного обеспечения. Последние исследования даже начали разделять классический технический долг и то, что называют cognitive debt и intent debt, потерю общего понимания системы и причин, по которым когда-то были приняты определённые решения.

Когда мы работали над этими проектами, мы, конечно, не пользовались такими терминами.

Моя формулировка была гораздо проще. Почему мы тратим столько времени, чтобы вспомнить то, что когда-то сами же построили?

ИНОГДА СИСТЕМА СТАРЕЕТ ИМЕННО ПОТОМУ, ЧТО ПРОДУКТ ЖИЛ

Один из наших e-commerce проектов работает уже больше пяти лет.

Первую версию мы построили на базе open-source CMS. На тот момент это было правильное решение. Бизнесу нужна была платформа электронной коммерции. Основным направлением был B2C. B2B существовал, но оставался лишь небольшой частью бизнеса. Именно под такую модель и строилась система.

Потом мы начали её развивать. И очень активно. Мы анализировали поведение пользователей. Изучали тепловые карты. Переделывали карточки товаров. Меняли каталог. Улучшали интерфейс. Перемещали элементы. Добавляли новую логику. Подключали новые сервисы.

Бизнес продолжал работать. Продукт продолжал меняться вместе с ним.

И именно это здесь самое важное. Система не пролежала пять лет без изменений. Она прожила эти пять лет вместе с бизнесом.

Заброшенная система устаревает потому, что к ней никто не прикасается. Живой продукт, наоборот, становится всё сложнее именно потому, что над ним постоянно работают.

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

Код остался. Контекст, нет.

Иногда технический долг не признак того, что продуктом никто не занимался. Наоборот. Это признак того, что им занимались много лет.

ПОТОМ ИЗМЕНИЛСЯ САМ БИЗНЕС

Сам по себе технический долг не стал причиной перестройки системы. Если бы всё было настолько просто, этой статьи, скорее всего, не появилось бы.

Произошло нечто гораздо важнее. Изменился сам бизнес.

Несколько лет назад основным направлением был B2C. B2B существовал, но оставался второстепенным. Потом клиент пришёл с совершенно другим запросом. Теперь B2B и B2C нужно было разделить практически поровну.

На первый взгляд это выглядит как обычная задача для сайта. Добавить ещё один раздел. Создать несколько новых страниц. Переделать навигацию. Технически всё это возможно.

Но дело было уже не в страницах. B2B и B2C перестали быть двумя разделами одного сайта. Они стали двумя самостоятельными направлениями бизнеса. С разными задачами. С разным позиционированием. С разными сценариями взаимодействия. С разными требованиями к информации. Бизнес фактически разделился на две полноценные части.

А система всё ещё считала одну из них всего лишь разделом сайта.

Параллельно значительно усложнились фильтры. Каталог уже требовал структурной перестройки. Карточку товара нужно было переосмыслить. Поиск больше не соответствовал новым требованиям. ERP- и CRM-интеграции стали намного глубже. Сам бизнес диверсифицировался. Появились новые продукты.

И мы уже обсуждали вопросы, которых пять лет назад просто не существовало. Например, как каталог должен работать в AI-интерфейсах и как меняется сам поиск.

Старая CMS не провалилась. И вопрос был даже не в том, можем ли мы продолжать её дорабатывать. Могли.

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

ВОЗМОЖНО, ВЫ УЖЕ СТРОИТЕ НОВУЮ СИСТЕМУ. ПРОСТО ВНУТРИ СТАРОЙ.

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

Всё происходит гораздо прозаичнее. Появляется ещё одна задача. Нужно полностью переделать карточку товара. Хорошо. Потом каталог. Потом фильтры. Поиск. Новая интеграция. Другой сценарий для B2B. Новая логика работы с продуктами. Ещё одно направление бизнеса перестаёт помещаться в существующую структуру данных.

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

Но в какой-то момент стоит перестать смотреть на задачи по отдельности. Посмотрите на направление, в котором развивается продукт.

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

Иногда вы уже строите новую систему. Просто делаете это внутри старой.

Именно здесь привычное сравнение начинает вводить в заблуждение. Да, следующая доработка действительно стоит дешевле, чем полная перестройка. Конечно. Но вопрос уже не в том, дешевле ли задача №1847, чем новая платформа.

Вопрос в другом. Что происходит, если следующие двадцать важных задач начинаются одинаково? Сначала нужно понять, что уже существует. Это уже совсем другая статья расходов.

ПОСТОЯННАЯ ЦЕНА ПОНИМАНИЯ

Мне кажется, именно эту часть почти всегда недооценивают.

Когда говорят о стоимости поддержки продукта, обычно имеют в виду часы разработки. Добавить новую функцию. Исправить ошибку. Обновить интеграцию.

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

Хорошему специалисту нужно понять систему. CI помогает. Тесты помогают. Git-история помогает. Документация тоже. AI всё лучше помогает читать незнакомый код и быстрее находить взаимосвязи. Всё это действительно полезно.

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

Код может объяснить, что делает конкретное условие. Git покажет, когда оно появилось. Тесты покажут, что сломается, если его удалить. Но это всё ещё не отвечает на другой вопрос. Нужно ли такое поведение бизнесу сегодня?

Кто-то всё равно должен связать старую реализацию с нынешней моделью работы компании.

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

Один разработчик разбирается с логикой каталога. Через несколько месяцев другой возвращается к тем же решениям, работая уже над поиском. Ещё через год команда меняет карточку товара и снова проходит часть того же самого пути.

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

Последние исследования начали описывать эту проблему гораздо точнее. Работа Маргарет-Энн Сторей 2026 года отделяет технический долг от cognitive debt и intent debt: код может оставаться, пока общее понимание системы и причины решений разрушаются. Сама Сторей формулирует эту разницу кратко: технический долг усложняет изменение систем, тогда как cognitive debt усложняет их понимание.

Это очень близко к тому, что я наблюдал на практике.

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

ПЕРЕСТРОЙКА НЕ НАКАЗАНИЕ ДЛЯ СТАРОЙ СИСТЕМЫ

Именно поэтому мне никогда не нравилась привычная риторика вокруг модернизации legacy-систем. Старая платформа тормозит развитие бизнеса. Предыдущая архитектура была ошибкой. CMS больше не масштабируется. Legacy-система себя исчерпала.

Иногда всё это действительно так. Но далеко не всегда.

В нашем случае первая система много лет отлично выполняла свою работу. Она поддерживала бизнес. Развивалась вместе с продуктом. Давала нам данные. Помогала понимать поведение пользователей. Именно благодаря ей компания выросла до того момента, когда B2B и B2C стали двумя полноценными направлениями.

Почему я должен называть это провалом?

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

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

Это уже совершенно другой разговор.

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

САМОЕ СЛОЖНОЕ ПОНЯТЬ, КОГДА НАСТУПИЛ ЭТОТ МОМЕНТ

Хотелось бы, чтобы существовала простая формула. Технический долг достиг 37%, пора перестраивать систему. Разработчики тратят больше четырнадцати часов на понимание старой логики, перестраиваем. В CMS больше шестидесяти модулей, перестраиваем.

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

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

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

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

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

Не каждый продукт приходит к этой точке. Наш, пришёл.

КОД ПОМНИТ ВСЕ ВЕРСИИ БИЗНЕСА

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

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

А система сохраняет всё. Стиль. Условие. Исключение. Поле. Интеграцию. Одну кнопку, за которой стоят пять лет решений.

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

Самое сложное, вовремя это признать. Особенно когда старая система всё ещё работает. Особенно когда её строил ты сам.

Возможно, именно тогда это сложнее всего.

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

Иногда после такого анализа самым ответственным решением становится не добавить ещё один слой. А построить следующую систему.