Що технічний борг у e-commerce насправді коштує

Ми працювали з магазинами на Magento, де за чотири-п'ять років накопичились модулі, які ніхто не пам'ятав звідки, оверрайди в три шари глибиною, і PHP 7.2 в продакшні — бо хтось боявся це чіпати. Жодного разу це не призводило до єдиного драматичного падіння. Просто кожна дрібниця ставала важчою: повільніший деплой, повільніша зміна, повільніший дебаг. Ось що насправді коштує борг.

Патерни, які ми бачимо знову і знову

Після достатньої кількості таких проектів одні й ті самі категорії повторюються:

• Розростання оверрайдів. Magento дозволяє перевизначити майже будь-який базовий клас або шаблон. Це фіча, але вона стає проблемою, коли оверрайди накопичуються роками без прибирання. Ми аудитували магазини з 300+ активними оверрайдами, і добра третина з них існувала для виправлення багів у версіях Magento, які магазин давно оновив. Кожне оновлення — це ручна археологія.
• Нетестовані кастомізації. Кастомна логіка без тестів не просто підвищує ймовірність багів — вона змінює поведінку команди. Інженери перестають впевнено вносити зміни. Деплої починають вимагати людину, яка дивиться на дашборди. Один клієнт описував свій процес релізів як «задеплоїти, помолитися, моніторити дві години». Це не проблема процесу — це проблема боргу.
• Захардкоджена бізнес-логіка. Правила доставки у вигляді захардкожених масивів у файлі шаблону. Податкові винятки в обсервері. Логіка промо розкидана по трьох різних плагінах. Коли вимоги змінюються — а вони змінюються завжди — хтось має відстежити кожне місце, де живе логіка, і сподіватися, що знайшов усі.
• Відкладені оновлення платформи. PHP 7.4 завершив підтримку наприкінці 2022 року. Ми все ще регулярно зустрічаємо його в продакшні. Запуск EOL-стеку — це не лише ризик безпеки: він відрізає від нових розширень, хостингових конфігурацій і з часом робить розрив оновлень настільки великим, що він перетворюється на окремий проект.

Де насправді ховається вартість

Є цифра, яку часто наводять — щось на кшталт 15–35% інженерної потужності, яку з'їдає борг на зрілих платформах. Це правдоподібно, але вона применшує проблему, бо враховує лише час, який явно витрачається на борг.

Більша вартість — поведінкова. Команди на сильно задовженій кодовій базі деплоять рідше. Не тому що не можуть — бо деплої непередбачувані. Зміна в одному модулі несподівано зачіпає інший. Починаєш збирати роботу в пакети, щоб скоротити кількість деплоїв. Час циклу зростає. Петлі зворотного зв'язку стають довшими.

Маркетинг запускає кампанію. Магазин не витримує сплеску трафіку, бо ніхто не чіпав шар кешування два роки і немає безпечного способу змінити його під тиском дедлайну. Це борг. Новий партнер з інтеграцій вимагає сучасний API — але платформа на версії, яка його не підтримує. Це теж борг.

Що насправді варто виправляти

Не весь борг варто усувати. Частина з нього погана, але стабільна — не мінялася два роки і, мабуть, не зміниться. Витрачати на неї час — зазвичай неправильне рішення. Ось як ми думаємо про пріоритизацію:

1. Чи знаходиться він у коді, який ви регулярно чіпаєте? Борг у модулі, який змінюється кожен спринт, дорогий. Борг у модулі, який ніхто не відкривав з 2021 року, фактично інертний. Починайте з того, що активно вас гальмує, а не з того, що просто виглядає погано.
2. Чи блокує він потрібне оновлення? Якщо модуль використовує застарілі API або несумісний із наступною версією Magento чи PHP — у боргу є дедлайн. Ви все одно заплатите — краще на своїх умовах, ніж під тиском.
3. Чи може він спричинити інцидент для користувача? Нетестований код у вашому флоу чекауту — це інша категорія проблеми, ніж нетестований код у внутрішньому адмін-звіті. Баги чекауту безпосередньо коштують виручки. Пріоритизуйте борг, що сидить у високонавантажених, критичних для доходу шляхах.

Рефакторинг чи переписування

Переписування зринає рано чи пізно в більшості розмов про серйозний борг. Наша чесна думка: зазвичай це неправильна відповідь. Повне переписування платформи — мінімум 12–18 місяців, воно виробляє нову кодову базу зі своїм набором проблем, і блокує доставку функцій на весь цей час. Дуже мало бізнесів можуть собі це дозволити.

Цільовий рефакторинг — модуль за модулем, тести по дорозі, заміна найгірших оверрайдів чистими реалізаціями — повільніший з точки зору чистого throughput коду. Але він тримає бізнес у русі. Ми бачили команди, які скорочували час циклу фічі на 60–70% за шість місяців саме так, не зупиняючи нічого іншого.

Єдиний випадок, де міграція неминуча: коли сама платформа EOL. Magento 1 — очевидний приклад. Тут рефакторингом не відбутися — треба рухатися. Навіть тоді поетапна міграція (спочатку каталог, потім чекаут, потім інтеграції) майже завжди краща за big-bang перехід. Big-bang концентрує весь ризик в одному вікні запуску.

Як отримати підтримку поза інженерією

Борг майже неможливо пріоритизувати без підтримки бізнесу, а бізнес-стейкхолдери не реагують на абстрактні аргументи про якість коду. Що справді працює: зробити його конкретним. «Цей модуль займає 4 години на безпечну зміну, бо у нього немає тестів. З тестами — 45 хвилин. Ми міняємо його приблизно 20 разів на рік. Це 65 інженеро-годин накладних витрат, які зникнуть, якщо ми витратимо два спринти на покриття». Такий фрейм рухає розмови так, як «у нас багато технічного боргу» ніколи не рухає.