Технический долг в legacy-магазине: как оценить и сокращать

Магазин работает пятый год, приносит деньги — но каждая доработка занимает вдвое дольше, чем должна, релизы страшно выкатывать, а обновить 1С-Битрикс никто не решается: «слетит». Это не «плохие разработчики» и не «пора всё переписать». Это накопленный технический долг — сумма решений, принятых когда-то ради скорости, за которые бизнес теперь платит замедлением при каждом изменении.

Разберём практично: что считать техническим долгом в магазине на 1С-Битрикс, как его инвентаризировать и оценить, как приоритизировать и сокращать эволюционно, не останавливая продажи, и как не скатиться обратно в legacy. Системную работу с долгом и производительностью закрывает наш аудит и оптимизация 1С.

Что такое технический долг и откуда он берётся

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

Важно: не всякий долг плох. Осознанно взятый долг ради выхода в срок — нормальная инженерная практика, если о нём помнят и возвращают. Проблема начинается, когда долг берётся неосознанно и не отдаётся: он накапливается, и в какой-то момент «проценты» съедают всю скорость команды. Legacy-магазин — это как раз система, где долг копился годами без возврата.

Типовой долг в магазине на 1С-Битрикс

У магазинов на 1С-Битрикс долг принимает узнаваемые формы. Знание типовых мест ускоряет инвентаризацию:

• Правки ядра. Изменения в файлах /bitrix/modules/ вместо кастомизации через события и наследование.
• Правки стандартных компонентов. Редактирование системных компонентов вместо копирования в свой namespace.
• Устаревшее API. Старые методы вместо D7 ORM, прямые SQL-запросы вместо сущностей.
• Дублирование логики. Одинаковый код в шаблонах и компонентах, скопированный десять раз.
• Отсутствие тестов. Любое изменение проверяется вручную и «на глаз».
• Ручные операции. То, что давно надо было автоматизировать: выгрузки, синхронизации, отчёты.

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

Правки ядра — самый дорогой долг

Отдельно стоит выделить правки ядра, потому что это долг с самыми тяжёлыми процентами. Как только кто-то поправил файл в /bitrix/modules/, система теряет способность спокойно обновляться: обновление либо затрёт правку и что-то сломается, либо конфликтует с ней.

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

Как оценить долг: реестр и две оси

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

Две оси — риск и стоимость — дают карту, по которой видно, за что браться. Реестр стоит вести живым документом: новые находки дописываются, сделанное отмечается. Без такой карты команда хватается за самое заметное или самое интересное, оставляя по-настоящему опасное на потом.

Приоритизация: риск против стоимости

Имея оценку по двум осям, приоритеты расставляют по понятной логике:

1. Высокий риск, низкая стоимость. Делать немедленно — максимум пользы за минимум усилий.
2. Высокий риск, высокая стоимость. Планировать как проект — опасно оставлять, но требует ресурса.
3. Низкий риск, низкая стоимость. Делать попутно, вместе с другими задачами в этих местах.
4. Низкий риск, высокая стоимость. Откладывать или не трогать — дорого и не критично.

Главное — не путать «раздражает разработчика» с «опасно для бизнеса». Некрасивый, но стабильный код с низким риском может годами ждать своей очереди, а вот правки ядра или отсутствие тестов на оформлении заказа разбирают в первую очередь, даже если «оно вроде работает».

Перевод долга на язык бизнеса

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

• Скорость разработки. «Каждая доработка каталога занимает вдвое дольше из-за дублирования и правок ядра».
• Безопасность. «Мы три года не обновляемся, накопились незакрытые уязвимости».
• Стабильность. «При каждом релизе что-то падает, потому что нет тестов на критичных сценариях».
• Упущенные возможности. «Не можем внедрить новую функцию, пока не разберём этот узел».

Когда долг связан с конкретными потерями, сокращение становится инвестицией с понятной отдачей. Бизнес готов вкладываться в «ускорить разработку на 30%», но не в абстрактную «уборку кода». Язык рисков и денег — обязательный навык для того, кто хочет получить ресурс на рефакторинг.

Эволюция вместо переписывания с нуля

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

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

Вынос правок ядра в поддерживаемые механизмы

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

• Обработчики событий. Логику, вставленную в ядро, переносят на события 1С-Битрикс — они официально поддерживаются и не слетают.
• Наследование компонентов. Правленые системные компоненты копируют в свой namespace и меняют там.
• Собственные модули. Крупную кастомную логику оформляют отдельным модулем с чистым API.
• Проверка обновляемости. После выноса систему пробно обновляют на тестовом контуре — правки больше не мешают.

Как аккуратно оформлять кастомную логику модулем, а не правкой ядра, мы подробно разбираем в статье про разработку собственного модуля на Битрикс. Это возвращает системе способность обновляться — а значит, снимает самый дорогой долг.

Обновление API: переход на D7

Второй крупный пласт долга — устаревшее API. Старый код магазина часто написан на устаревших методах и прямых SQL-запросах, тогда как современный 1С-Битрикс предлагает D7 ORM: типизированные сущности, безопасные запросы, читаемый код.

Переход на D7 делают не одним махом, а кусками: берут участок (например, работу с заказами), покрывают его тестами по текущему поведению, переписывают на ORM, проверяют, что поведение не изменилось, выкатывают. Так устаревшее API уходит постепенно, без риска сломать всё сразу. Подробно про переход и преимущества D7 — в материале про D7 ORM в Битрикс. Новый код на D7 не только чище, но и меньше склонен порождать новый долг.

Рефакторинг без остановки бизнеса

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

1. Покройте участок тестами. Зафиксируйте текущее поведение, чтобы поймать регрессии.
2. Меняйте небольшими порциями. Один узел за раз, а не «весь каталог сразу».
3. Проверяйте на тестовом контуре. Каждое изменение прогоняется до боевого выката.
4. Выкатывайте через контролируемый деплой. С возможностью быстрого отката, если что-то пошло не так.
5. Наблюдайте после релиза. Следите за ошибками и метриками, чтобы поймать проблему рано.

Основа безопасного рефакторинга — надёжный процесс выкатки с откатом. Без него каждый шаг превращается в риск для продаж. Как выстроить такой процесс, мы разбираем в статье про CI/CD и деплой на Битрикс, а вопросы стабильной среды — в материале про инфраструктуру и хостинг на BitrixVM.

Как не копить долг снова

Разобрать старый долг мало — важно не накопить новый. Иначе через год система снова сползёт в legacy. Удерживают её несколько правил:

• Не править ядро — никогда. Правило без исключений, иначе всё начинается заново.
• Код-ревью изменений. Второй взгляд ловит быстрые «временные» решения до того, как они станут долгом.
• Тесты на критичное. Оформление заказа, оплата, обмен с 1С покрыты тестами по умолчанию.
• Фиксация осознанного долга. Если долг взят сознательно ради срока — он записывается в реестр, чтобы вернуться.
• Деплой через CI/CD. Контролируемая выкатка не даёт «наливать» изменения мимо процесса.

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

Частые ошибки

• Переписать всё с нуля. Останавливает бизнес и порождает новый долг ещё до запуска.
• Рефакторить без реестра. Хватаются за заметное, оставляя опасное на потом.
• Путать «раздражает» и «опасно». Красивят стабильный код вместо разбора правок ядра.
• Менять большими кусками. Ломают всё сразу вместо малых безопасных шагов.
• Рефакторить без тестов. Нет способа поймать регрессию, каждая правка — риск.
• Говорить с бизнесом на языке кода. «Плохой код» не даёт ресурса; нужен язык денег и рисков.
• Разобрать и не завести правил. Долг возвращается за год, если не менять привычки.

Чек-лист и вывод

1. Реестр долга составлен. Все известные проблемные места записаны и оценены.
2. Оценка по двум осям. Каждый пункт — риск для бизнеса и стоимость исправления.
3. Приоритеты расставлены. Высокий риск при низкой стоимости — в первую очередь.
4. Долг переведён на язык бизнеса. Есть обоснование ресурса через деньги и риски.
5. Правки ядра разбираются первыми. Логика вынесена в события и модули, обновляемость восстановлена.
6. API обновляется на D7. Устаревшие методы уходят кусками с тестами.
7. Рефакторинг безопасен. Малые шаги, тесты, деплой с откатом.
8. Правила против нового долга. Не править ядро, ревью, тесты, фиксация осознанного долга.

Технический долг в legacy-магазине — не приговор и не повод всё переписывать. Это управляемая величина: его можно измерить, приоритизировать и сокращать эволюционно, не останавливая продажи. Начните с реестра и оценки по риску и стоимости, разберите в первую очередь правки ядра и отсутствие тестов на критичных сценариях, переводите долг на язык бизнеса — и двигайтесь малыми безопасными шагами. А чтобы не копить долг снова, заведите правила и держите дисциплину. Тогда старый магазин снова станет системой, которую приятно и быстро развивать.