Технический долг сайта на Битрикс: реестр, план погашения и проверка результата

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

Что такое технический долг сайта на Битрикс и где его границы

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

У технического долга сайта на Битрикс есть границы, которые полезно зафиксировать до начала работ.

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

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

Признаки системной проблемы: как отличить долг от разовой поломки

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

Повторяемость

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

Стоимость правки

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

Связанность

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

Ручные операции

Регулярные ручные операции (выгрузка, сверка, обновление цен), которые забывают или выполняют по-разному, — это долг. Он опасен тем, что не проявляется, пока кто-то внимателен, и даёт сбой, когда внимание теряется.

Отсутствие проверок

Отсутствие тестов и регрессионных сценариев делает каждое изменение рискованным. Это тоже долг, даже если код выглядит аккуратно.

Реестр технического долга: структура и правила ведения

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

Минимальный набор полей:

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

Правила ведения простые, но их важно соблюдать.

1. Одна запись — одна проблема. Не объединяйте «почистить шаблоны и заодно переписать интеграцию». 2. У каждой записи есть критерий готовности, сформулированный проверяемо. «Стало лучше» — не критерий. 3. Реестр пересматривается по расписанию, а не только когда «горит». 4. Записи, которые перестали быть актуальными, закрываются с пометкой причины, а не удаляются молча. 5. Реестр живёт там, где команда реально работает, а не в отдельном файле, который никто не открывает.

Как собрать исходные данные для оценки

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

Что запросить у бизнеса

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

Что запросить у команды

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

Что проверить на самом сайте

• Как ведёт себя ключевой сценарий при типовых действиях пользователя.
• Что происходит при ошибке внешнего сервиса.
• Есть ли резервные копии и проверялись ли они на восстановление.
• Как устроен доступ: кто и что может менять.

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

План погашения без остановки развития

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

Шаг 1. Приоритизация

Разложите записи реестра по двум осям: влияние на бизнес и стоимость работ. Первыми идут записи с высоким влиянием и умеренной стоимостью. Записи с высоким влиянием и высокой стоимостью планируются отдельно, с этапами. Записи с низким влиянием ждут.

Шаг 2. Группировка

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

Шаг 3. Подготовка

Перед любым изменением:

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

Шаг 4. Выполнение

Работайте маленькими шагами с проверкой после каждого. Если пакет затрагивает критичный сценарий, проверяйте его отдельно и до, и после.

Шаг 5. Закрытие записи

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

Таблица принятия решения

Учебный пример: разбор условного проекта

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

Входные условия

Условный интернет-магазин на Битрикс с каталогом, корзиной и интеграцией с учётной системой. Развитие идёт: маркетинг просит новые акции, ассортимент растёт. Команда небольшая, поддержка ведётся по обращениям.

Что известно на старте:

• цены и остатки обновляются частично вручную;
• расчёт скидок продублирован в нескольких местах;
• после релизов периодически всплывают ошибки в корзине;
• документация по интеграции устарела;
• резервные копии делаются, но восстановление не проверялось.

Что делаем

1. Собираем реестр: фиксируем каждую проблему отдельной записью с наблюдаемым следствием. 2. Приоритизируем: сначала расчёт скидок и обновление цен, потому что они влияют на выручку и на доверие клиентов. 3. Готовимся: делаем копию, проверяем восстановление на тестовом контуре, фиксируем текущее поведение корзины. 4. Закрываем пакетами: сначала сводим расчёт скидок в одно место и закрываем проверками; затем разбираем обновление цен; затем обновляем документацию по интеграции. 5. После каждого пакета проверяем ключевой сценарий покупки и сверяем данные с учётной системой.

Проверка результата

• Расчёт скидок даёт одинаковый результат во всех местах, где он используется.
• Обновление цен и остатков выполняется по описанному процессу, ручные шаги сведены к контролю.
• Ключевой сценарий покупки проходит без ошибок после каждого релиза.
• Документация по интеграции соответствует фактическому поведению.
• Восстановление из резервной копии проверено на тестовом контуре.

Что осталось за рамками

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

Как проверить результат и принять работу

Приёмка долга отличается от приёмки обычной доработки. Здесь важно убедиться не только в том, что «стало работать», но и в том, что стало проще менять.

Критерии приёмки

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

Чек-лист приёмки

• Критерий готовности каждой записи сформулирован проверяемо и выполнен
• Ключевые сценарии проверены на тестовом контуре до изменений
• Ключевые сценарии проверены после изменений
• Поведение при недоступности внешнего сервиса проверено
• Резервная копия сделана перед работами
• Восстановление из копии проверено
• План возврата подготовлен и понятен команде
• Документация обновлена по фактическому поведению
• Реестр обновлён: статусы и даты пересмотра актуальны
• Владелец каждой закрытой записи подтвердил результат

Типичные ошибки и ограничения

Ошибки в работе с долгом повторяются, и их полезно знать заранее.

• Попытка закрыть всё сразу. Большой рефакторинг без промежуточной проверки повышает риск, а не снижает его.
• Отсутствие критерия готовности. Без него запись нельзя закрыть, и она висит годами.
• Смешивание долга и текущей поддержки. Тогда реестр теряет приоритеты.
• Работа без копии и плана возврата. Это прямое нарушение порядка работ.
• Оценка «на глаз». Без входных данных оценка превращается в обещание, которое сложно подтвердить фактурой.
• Игнорирование документации. Если её не обновлять, долг возвращается вместе с новым человеком в команде.

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

Ответственные и роли

У долга должен быть владелец. Обычно это руководитель проекта или технический руководитель со стороны подрядчика, который ведёт реестр и отвечает за приоритеты. Бизнес-владелец подтверждает влияние на процессы и приоритеты. Разработчики отвечают за выполнение и за критерии готовности. Если сайт на регулярной поддержке сайта на Битрикс, реестр удобно вести в рамках этого контура, чтобы работы не терялись между обращениями.

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

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

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

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

Такой подход не обещает мгновенного эффекта. Он даёт управляемость: понятно, что накопилось, что делаем дальше и как поймём, что стало лучше.