Чек-лист технического долга: насколько плоха ваша кодовая база?

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

Ключевые выводы

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

В нашем опыте спасение среднего B2B-маркетплейса занимало от 6 до 10 недель, но каждый проект уникален.

Автотесты, которые не запускаются, хуже их отсутствия: они дают ложное спокойствие.

Каждый месяц откладывания спасения проекта обходится в скрытые потери на скорости команды и упущенные возможности.

Начните с одного пункта чек-листа, а не с попытки всё исправить сразу.

Что такое технический долг на самом деле?

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

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

Мы в Softwhere.uz специализируемся на спасении проектов — видели десятки кодовых баз, где бизнес ещё держится, а разработка едет в тартарары. Разница между «немного долга» и «катастрофой» часто неочевидна невооружённым глазом. Отсюда и чек-лист.

Почему вам стоит переживать за здоровье кодовой базы?

Он не отражается в бухгалтерии отдельной строкой. Но его последствия реальны:

Фичи выходят в 3–5 раз дольше, чем должны. Конкуренты обгоняют.
Ключевые разработчики уходят — работать с легаси-кодом неприятно и непрестижно.
Простые баги превращаются в инциденты, потому что никто не понимает, как система реагирует на изменения.
Интеграции обходятся дороже — API кривые, документации нет, каждый подключённый сервис требует костылей.

Предположим, у вас маркетплейс с выручкой $X. Если команда из пяти разработчиков тратит существенную долю времени на борьбу с долгом — это эквивалент части ставки, которая не работает на рост.

Мы не говорим, что технический долг нужно искоренять полностью. Вопрос — контролируете ли вы его, или он контролирует вас.

Как технический долг работает на практике?

Долг растёт по сложным процентам. Вот механика:

Сначала команда принимает «быстрое» решение. Например, хранит данные покупателей прямо в заказе, вместо отдельной таблицы. Экономит неделю. Через полгода появляется потребность в личном кабинете — а данные размазаны по сотням заказов. Переделка теперь затрагивает всю систему. Команда добавляет «временный» скрипт для синхронизации. Ещё через год таких «временных» решений десяток, они конфликтуют друг с другом, и любое изменение требует правки в пяти местах.

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

Вот почему мы не верим в совет «просто выделите 20% времени на рефакторинг». Без диагностики это как лечить головную боль аспирином, не зная, мигрень это или давление. Нужен чек-лист, нужна приоритизация, нужен план.

Что покрывает наш чек-лист технического долга?

Мы проверяем семь областей. Каждый вопрос — бинарный: да или нет. Три и более «нет» — повод серьёзно задуматься о спасении проекта.

Может ли новый разработчик развернуть проект за один день?

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

Как давно вы обновляли зависимости?

Фреймворки, библиотеки, операционные системы — всё устаревает. Не обновляли год? Два? Каждое пропущенное обновление умножает риск уязвимостей и стоимость следующего обновления. Мы видели проекты на версиях Python или Node, которые перестали получать security-патчи три года назад. Обновление такого — проект на месяцы, не на дни.

Есть ли автотесты, которые реально запускаются?

Тесты, которые никто не запускает, — хуже отсутствия тестов. Они дают иллюзию безопасности. Проверьте: когда последний раз падал CI-пайплайн? Если никогда — скорее всего, он не работает. Если команда боится запускать тесты перед релизом — они бесполезны.

Можете ли вы деплоить без страха?

Пятничный деплой — мем, но за ним правда. Если релиз требует ручных проверок в 23:00, откат занимает час, а команда молится, чтобы ничего не упало — процесс сломан. Хороший деплой: нажал кнопку, через 10 минут всё в продакшене, откат — ещё 5 минут.

Есть ли код, который никто не осмеливается трогать?

«Это лучше не трогать, а то всё сломается» — классический признак. Обычно это критический модуль, написанный ушедшим разработчиком, без тестов, с непонятными зависимостями. Каждая команда знает такие места. Чем их больше, тем медленнее двигаетесь.

Сколько «временного» кода всё ещё работает?

Временные решения имеют свойство окаменевать. Скрипт для миграции данных, который «уберём через месяц». API-заглушка для интеграции, которая «пока так». Флаг функциональности, который «временно» отключает проверку. Если «временное» живёт больше полугода — оно постоянное.

Вы знаете, где живут ваши данные?

База данных на сервере, который никто не мониторит. Бэкапы, которые никто не проверял на восстановление. Личные данные клиентов в логах. GDPR, локальные законы о персональных данных — невидимость данных не освобождает от ответственности.

Пример: как выглядит спасение проекта

Возьмём типичный кейс для нашего региона. Бизнес: B2B-маркетплейс в Центральной Азии, три года работы, 12 000 активных пользователей в месяц, $80 000 выручки. Основатели построили первую версию с офшорным агентством, потом наняли двух разработчиков, которые ушли за год. Сейчас команда из трёх человек боится трогать ядро системы.

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

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

Иллюстративный пример: распределение затрат на спасение проекта B2B-маркетплейса (USD, гипотетические данные)

Процесс занимает 8–10 недель. Первые две — аудит и стабилизация, чтобы ничего не сломалось. Потом параллельно идёт обновление инфраструктуры и рефакторинг самых болезненных модулей. Автоматизация деплоя и тестов — в середине, чтобы ускорить оставшуюся работу. Последние две недели — приёмочное тестирование и передача знаний команде.

Мы не начинаем спасение без такой оценки. Хотите примерный диапазон для вашего проекта — оцените за две минуты в нашем калькуляторе.

Где мы видим, как долг давит на бизнес

Три типичных сценария из нашей практики:

Стартап после раунда. Получили инвестиции, наняли 10 разработчиков — а кодовая база не тянет параллельную работу. Конфликты при слиянии кода, постоянные регрессии, команда тратит 60% времени на починку, а не на продукт. Инвесторы ждут роста, а скорость падает.

Зрелый бизнес с легаси-системой. Работает 5–7 лет, приносит деньги, но любая интеграция — проект на месяцы. Хотят подключить Payme, Click, Uzum — а API построен так, что каждый платёжный провайдер требует уникального костыля. Конкуренты с современной архитектурой подключают за неделю.

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

Словарь терминов

Рефакторинг — переписывание кода без изменения поведения, чтобы сделать его понятнее и проще в поддержке. Как перекладка проводки в квартире: розетки на тех же местах, но не пожароопасно.

Легаси-код — код, который работает, но никто не хочет в нём разбираться. Часто без тестов, без документации, с непонятными зависимостями.

CI/CD — автоматизация проверки и выкладки кода. Хороший CI/CD: разработчик отправил изменения, система сама проверила, протестировала и выложила.

Зависимости — чужой код, который вы используете: фреймворки, библиотеки, инструменты. Устаревшие зависимости — дыры в безопасности и препятствия для обновления.

Деплой — процесс выкладки новой версии на рабочие серверы. Ручной деплой рискован и медленен, автоматический — предсказуем.

Регрессия — когда исправление одного ломает другое. Частый симптом высокого технического долга: система хрупкая, связи неявные.

Распространённые заблуждения

«Перепишем с нуля — будет дешевле»

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

«Технический долг — проблема разработчиков, не бизнеса»

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

«Наняли бы лучших разработчиков — не было бы долга»

Хорошие разработчики в легаси-системе уходят быстрее плохих. Потому что видят, что 80% усилий уходит на преодоление фундамента, а не на создание ценности. Сначала среда, потом люди.

«Мы просто выделим 20% времени на технический долг»

Без приоритизации это размывание фокуса. Какие 20%? Что именно чинить? Чек-лист даёт ответы, а не расплывчатые обещания.

Как начать: ваши следующие шаги

Не пытайтесь исправить всё сразу. Вот практичный порядок:

Неделя 1–2: самодиагностика. Пройдите наш чек-лист с командой. Отметьте «нет» честно, без оправданий. Зафиксируйте время, которое уходит на «пожаротушение» против продуктовой работы.

Неделя 3: приоритизация. Один пункт с наибольшим бизнес-влиянием. Обычно это либо «развёртывание за день» (ускоряет всех новых людей), либо «деплой без страха» (уменьшает инциденты). Не пытайтесь взять три.

Месяц 1–3: первый блок. Доведите выбранный пункт до «да». Измерьте, как изменилась скорость команды. Это данные для обоснования дальнейших инвестиций.

Квартал 2–3: следующие блоки. По одному за раз, с измерениями между ними.

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

Хотите понять, подходит ли спасение проекта вашему бизнесу?

Три вопроса для самопроверки:

Новая функция занимает в 3+ раза больше времени, чем кажется логичным?
Ключевые разработчики уходят, а новые не задерживаются?
Вы откладываете интеграции или рынки из-за «сложностей с платформой»?

Если хотя бы два «да» — стоит разговор.

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

Частые вопросы

Как понять, мой технический долг «нормальный» или опасный?

Нормальный долг — когда вы знаете, где срезали углы, и можете оценить стоимость переделки. Опасный — когда не знаете, сколько его, где он, и каждое изменение непредсказуемо. Чек-лист выше даёт конкретные маркеры. Три и более «нет» — повод действовать, не откладывать.

Можно ли измерить технический долг в деньгах?

Не точно, но достаточно хорошо для решений. Считайте время команды на долг-related работу: починка багов, ручное тестирование, разбор инцидентов, ожидание деплоев. Умножьте на полную стоимость разработчика (зарплата, налоги, офис, оборудование — обычно 1,3–1,7× зарплаты). Добавьте упущенную выручку от невышедших в срок фич. Получится консервативная оценка, достаточная для приоритизации.

Стоит ли рассказывать инвесторам о техническом долге?

Обязательно, но с переводом на бизнес-язык. Не «наш код грязный», а «мы накопили инфраструктурные упрощения, которые замедляют выход фич в 3 раза. Инвестиция $X в стабилизацию вернётся за Y месяцев за счёт скорости команды». Честность с планом лучше скрытия, которое вскроется при due diligence.

Сколько обычно длится спасение проекта?

Диапазон широкий: от 4 недель для небольших систем до 6 месяцев для крупных платформ. Наш типичный кейс среднего B2B-маркетплейса — 6–10 недель. Критичнее сроков ритм: мы работаем итерациями по 2 недели с демонстрируемыми результатами, чтобы бизнес видел прогресс, а не чёрный ящик.

Можно ли продолжать выпускать фичи во время спасения?

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