Привет! Меня зовут Ира, я тимлид проекта по развитию чатов поддержки в компании «Совкомбанк Технологии». Уже более пяти лет я занимаюсь фронтенд‑разработкой и часто сталкивалась с проектами, где накопленный технический долг замедляет работу команды и усложняет развитие продукта. Этот опыт научил меня не просто исправлять код, а выстраивать стратегию его постепенного и безопасного улучшения без остановки основной разработки.
В сети много инструкций по рефакторингу, но они часто описывают идеальные условия или узкие сценарии. Я же покажу наш подход на живых примерах, с расстановкой приоритетов и оценкой рисков. Материал будет особенно полезен тем, кто работает в проектах с долгой историей и вынужден совмещать поддержку старого кода с внедрением новых решений.
Именно в такой ситуации оказалась наша команда, когда мы взялись за текущий проект с 8-летней историей. Около 80% его кодовой базы требовало глубокой переработки. Коллеги ранее предпринимали множество попыток рефакторинга, но системного подхода не хватало, изменения оставались точечными и не доводились до конца.
В этой статье подробно расскажу, как мы выстроили работу с техническим долгом на этом проекте: с чего начали, как приоритизировали задачи, какие инструменты и процессы внедрили, каких результатов удалось достичь. А начну с того, с чем нам пришлось столкнуться в самом начале:
Хаос в коде: сотни пометок TODO и FIXME без контекста; три библиотеки для кэширования и синхронизации данных с одинаковой, функциональностью; устаревшие языковые конструкции из каменного века JS (типа ~arr.indexOf)).
Разношерстный стек: три кардинально разных подхода к стилям: scss, tailwind, styled components.
Угрозы безопасности: сотни уязвимостей в каждом анализе.
Низкая скорость: сборка в дев‑режиме занимала больше пяти минут.
Последствия были очевидны: наши разработчики не могли сосредоточиться на бизнес задачах, потому что тратили 60% времени на то, чтобы понять «почему это не работает», а погружение новых ребят в проект занимало месяцы. При этом новые требования поступали очень быстро, а попытки справляться с проблемами в процессе работы над бизнес‑задачами приводили к срывам сроков.
Важно понять, что полностью от технических долгов мы не избавимся никогда. Это удобный инструмент для работы и естественная часть процесса разработки. Это становится понятно, если разобрать долги по типу их возникновения:
Осознанный: возникает при проверке гипотез или в условиях жёстких дедлайнов.
Случайный: возникает у разработчиков с небольшим опытом, новичков на проекте и при использовании редких технологий.
Естественный: возникает при устаревании библиотек и кода.
Такая классификация дает понять, что технический долг может встретиться нам в любой момент.
Для нас было важно не отсутствие долга, а контроль над ним. Именно этот контроль стал основой для построения устойчивого процесса, который позволяет не просто бороться с последствиями технического долга, а системно управлять им — на уровне команды, процессов и инструментов.
Вот как я и моя команда реализовали это на практике
План действий был следующим:
1. Подготовка и организация процесса
Три ключевых шага, которые следует сделать в первую очередь:
Изучите внутренние регламенты вашей компании. Нередко в больших компаниях есть рекомендуемые схемы работы с техдолгом или позитивный опыт других команд.
Организуйте технические встречи команды. В нашем случае мы проводили такие встречи раз в неделю. На более свежих проектах достаточно проводить встречи один раз в месяц. Они необходимы на каждом этапе и требуют вовлечения всей команды.
Создайте отдельный раздел на вашей платформе совместного управления проектами с категорией «Техдолг» и отдельную таблицу со списком этих задач.
2. Выявление проблем
На этом этапе очень важно не стремиться к абсолютной полноте, в процессе задачи будут приходить и уходить. Достаточно начать со списка самых очевидных проблем и нескольких задач для исследования.
Ручная проверка кода
Начните с простого: пройдитесь по всему проекту и соберите список всех комментариев TODO, FIXME, HACK и любых меток, которые указывают на незавершённую или проблемную логику.
В легаси‑проектах, где код писался годами разными людьми, контекст быстро теряется, поэтому лучше сразу создавать задачу на каждую найденную проблему. Кратко опишите, что, по вашему мнению, планировалось исправить или доработать. Если контекст неясен, то не стоит тратить время на этот этапе, можно пометить задачу как исследовательскую.
Если задачи простые и однотипные, их можно сгруппировать.
Технические предупреждения
Все предупреждения из консоли браузера и терминала: React Hook useEffect has a missing dependency, no‑unused‑vars, implicit any.
Заглушки по типизации, особенно в TypeScript‑проектах: any, unknown, @ts-ignore, // @ts-expect-error.
Предупреждения от линтеров: ESLint, TSLint, Stylelint.
Проблемы, специфичные для конкретного проекта: например, отсутствие атрибутов alt у изображений, неоптимизированные запросы, дублирование стилей.
Скорость и качество разработки
Мы замеряли метрики на каждом этапе, чтобы отслеживать эффективность наших стараний. Это тоже отдельные технические задачи. Ниже я приведу примеры из нашего проекта, но вам стоит ориентироваться на те метрики, которые характерны именно для вашего проекта.
Скорость сборки и размер бандла в dev и prod режимах. Для замера мы использовали Webpack Bundle Analyzer и Speed Measure Plugin. Мы поставили исследовательскую задачу с целью снизить время сборки с пяти и более минут до двух‑трех и уменьшить размер бандла на 30%. Спойлер: мы переехали с webpack на rsbuild, убрали кучу мусора из кода и поработали со статикой.
Velocity и TTM (Time to Market) — скорость выполнения задач. Мы измеряли среднее время от начала разработки до релиза с целью увеличить скорость на 20%, сократить TTM на 15%. Эта задача у нас на постоянном мониторинге: показатели улучшаются каждый месяц на 0,5–2%.
Количество багов на тесте и в проде. Мы собирали статистику по количеству багов, найденных на каждом этапе (unit, e2e, ручной тест, прод), чтобы понять, как техдолг влияет на качество, и с целью снизить количество багов в проде на 20%. В идеале стоит также учитывать вес багов.
Средства автоматизации и безопасности
У нас используются следующие методы анализа:
SAST (Static Application Security Testing) — статический анализ кода, который выполняется до компиляции и запуска приложения. Он работает на уровне исходного кода: сканирует файлы, ищет паттерны, которые могут указывать на уязвимости, плохие практики, нарушения архитектуры или несоответствие стандартам.
DAST (Dynamic Application Security Testing) — динамический анализ, который работает в процессе выполнения приложения. Он имитирует поведение пользователя и атакующего: отправляет запросы, проверяет ответы, ищет уязвимости в runtime, например, SQL‑инъекции, XSS, неправильные заголовки безопасности, открытые API.
SCA (Software Composition Analysis) — анализ состава программного обеспечения. Он сканирует все используемые библиотеки, фреймворки, пакеты и сравнивает их с базой известных уязвимостей. В отличие от SAST, он смотрит не на код, а на метаданные: версии, лицензии, CVE‑идентификаторы.
Secret Detection — анализ кода на наличие секретов в коде (API‑ключи, токены, пароли от баз данных, приватные ключи).
npm audit — встроенный инструмент npm, который проверяет зависимости в вашем проекте на наличие известных уязвимостей. Он работает на уровне package‑lock.json и сравнивает версии с базой уязвимостей, поддерживаемой npm. У многих пакетных менеджеров есть аналоги такой проверки, поэтому поищите их, если пишете на другом языке.
Искусственный интеллект
Мы создали несколько агентов для конкретных задач. Практически любое действие, описанное в этой статье, можно выполнить с их помощью, главное — это постоянная валидация. Но на начальном этапе достаточно простого описания agents.md с корректной архитектурой и правилами. Здесь я не буду углубляться в детали, так как это уже материал для отдельной статьи.
3. Оценка и приоритезация
Один из главных выводов, который мы сделали в процессе нашей работы с техническими задачами: управление техдолгом не отличается от работы с бизнес‑задачами. Здесь также необходим анализ: зачем решать именно эту проблему, насколько она критична, как повлияет ее выполнение или игнорирование на проект. Ключевая цель такого анализа ‑приоритизация задач.
Есть множество методик приоритизации, и у каждой из них есть свои преимущества и недостатки. Важно выбрать ту, которая подойдет именно вашему проекту. Ниже поделюсь несколькими подходами и своими выводами, в каких случаях удобно их использовать.
Скоринговая карта — метод, который мы позаимствовали у наших коллег‑экономистов и использовали для своего проекта. Его суть в том, чтобы оценить каждую задачу по определенным характеристикам, которым присваивается свой вес. Наша система оценок выглядела так:
Критерий
Вес
Описание
Критичность
40%
Влияние на безопасность, стабильность, пользователей
Влияние на команду
30%
Замедляет ли разработку/тестирование
Стоимость
20%
Оценка времени/ресурсов
Бизнес‑риск
10%
Возможные финансовые/репутационные потери
Приоритет = (Критичность × 0,4) + (Влияние × 0.3) + (Стоимость × 0,2) + (Риск × 0,1)
Оценка в часах
0–1
1–2
2–3
3–5
5–8
8–13
13–21
21–34
34–55
55 и больше
Оценка в поинтах
10
9
8
7
6
5
4
3
2
1
Для того, чтобы расчет был корректным, нужно оценить задачу по каждому критерию от 1 до 5 или 10 в зависимости от того, насколько детальная приоритизация вам нужна.
Для оценки стоимости нужно предварительно провести оценку в часах или сторипоинтах (мы используем для этого покер‑планирование), и определить рамки для каждого балла. Мы остановились на использовании урезанной последовательности Фибоначчи:
Тут важно отметить: если задача получает 2–3 поинта, ее стоит доработать и декомпозировать. В идеале одна задача не должна превышать 20 часов.
Задача
Критичность, поинты
Влияние на команду, поинты
Оценка, ЧЧ
Оценка, поинты
Бизнес‑риск, поинты
Приоритет
Состояние
Исправление состояния фокуса Chatinput и восстановление
8
9
30
3
5
7
done
Настройка CSP‑заголовков
10
4
24
3
3
6,1
done
Замена всех any в SearchPage
8
2
40
2
8
5
analyze
Настройка логгирования
5
1
6
8
4
4,3
in progress
Обновить реакт до 19.2.1
4
2
20
4
7
3,7
ready to develop
Преимущества этого подхода в высокой точности, универсальности и учете максимального количества факторов. Мы остановились на нем, так как для нас было важно учитывать оценку времени и ресурсов ввиду большой загруженности бизнес‑задачами.
Weighted Shortest Job First (WSJF) — взвешенный кратчайший срок выполнения. Методика из Scaled Agile Framework (SAFe) для оценки задач по формуле:
WSJF = (Cost of Delay) / (Duration)
Cost of Delay (CoD) — стоимость задержки: насколько дорого обойдётся, если не решить задачу сейчас? Состоит из трёх компонентов:
User‑Business Value — ценность для бизнеса или пользователя. В контексте работы с техдолгом есть смысл заменить ее на Technical Impact: насколько задача улучшит стабильность, производительность, безопасность.
Time Criticality — срочность задачи, например, уязвимость, блокирующая релиз.
Risk Reduction‑Opportunity Enablement — насколько задача снижает риски или открывает новые возможности.
Duration — продолжительность задачи в человеко‑днях или стори‑поинтах.
Каждый компонент оценивается от 1 до 5, и чем выше результат выполнения формулы, тем выше приоритет. Это тоже достаточно точный метод, но для нашего легаси‑проекта требовалась еще большая детализация.
Матрица приоритизации — верхнеуровневый метод, который подходит для малого количества задач.
Категория
Примеры задач
Приоритетность
Безопасность
Уязвимости, критические фиксы
Высший
Сопровождение
Критические баги от пользователей
Высокий
Разработка
Рефакторинг кода
Средний
Инфраструктура
Обновление устаревших библиотек
Низкий
Оценка по критериям — менее точный метод, но учитывает больше факторов.
Критичность
Блокирующий: уязвимости безопасности, падения системы.
Высокий: ошибки, влияющие на пользователей или бизнес‑процессы.
Средний: долг, усложняющий разработку, например, дублирование кода.
Низкий: косметические правки (оптимизация логов).
Влияние
Безопасность: угрозы взлома, утечки данных → всегда высокий приоритет.
Сопровождение: баги, нарушающие работу системы → приоритет зависит от частоты ошибок.
Разработка: долг, замедляющий команду, например, устаревшие библиотеки → средний/низкий приоритет.
Стоимость исправления
Быстрые правки можно включать в текущие спринты.
Крупные рефакторинги требуют отдельного планирования.
4. Как найти на это время?
Наверняка это главный вопрос, которым вы задаётесь на протяжении всего времени прочтения статьи.
Здесь я еще раз напомню, что прежде всего нужно обязательно узнать, как организована работа с техдолгом внутри компании. Возможно, есть утвержденная практика: проводить технические недели в конце квартала или выделять 10–20% емкости сотрудников на постоянной основе. Я не раз сталкивалась с тем, что разработчики просто не знают о таких возможностях.
Следующие пункты будут полезны, если принятых процессов нет или выделенного времени не хватает:
Ищем союзников в команде
Возможно у ваших коллег — тестировщиков, бэкендеров, дизайнеров — тоже есть потребность в «закрытии хвостов». Процесс станет для вас значительно легче, если вы объединитесь с кем‑то, кто уже часто взаимодействует с заказчиками. Это может быть ваш руководитель, менеджер или аналитик. В силу специфики своей работы у них может быть еще более полная картина ситуации и больше аргументов в пользу выделения ресурсов.
Учимся говорить на языке бизнеса: продаем задачи
Конечно, если прийти к представителю бизнеса и сказать: «Нам нужна новая версия реакта из‑за нового алгоритма рендеринга и сравнения нод», — это может произвести на него впечатление. Но появится вопрос: какую выгоду это принесет? Простого ответа «это ускорит работу сайта» будет мало. Важно представить цифры, прогнозы и визуализацию. Подход для каждой задачи и каждого проекта может быть разным. Приведу несколько примеров из нашего проекта:
Пример 1. На проекте не была реализована система моков, и фронтенд‑разработчики не могли взять задачу до того, как ее реализуют со стороны бэкенда. Мы выделили метрики, на которые влияет данная проблема, оценили текущие значения и спрогнозировали значения после реализации.
Метрика | Единица измерения | Текущее значение | Прогноз |
Время цикла разработки | День | 21 | 14 |
Скорость выполнения задач | Стори‑поинты | 12–15 | 13–16 |
Риск простаивания ресурса | Да/Нет | Да | Нет |
Временные затраты на реализацию | Стори‑поинты | 0 | 11–13 |
Наглядно показали, что чем раньше мы реализуем данную задачу, тем больше пользы получим.
Задачу утвердили и результаты оказались даже более приятными, чем мы ожидали.
Пример 2. На проекте использовался сильно устаревший WYSIWYG‑редактор, имеющий ряд недостатков: известные уязвимости, большой вес, проблемы с производительностью, отсутствие поддержки современных функций. Дальнейшее его использование было небезопасным и усложняло внедрение новых фич, связанных с форматированием текста. Мы собрали следующие метрики:
Метрика | Единица измерения | Текущее значение | Прогноз |
Количество ошибок при публикации (сломанные ссылки, неправильный HTML) | Количество ошибок в месяц | 20–50 | <20 |
Уровень удовлетворённости пользователей | Баллы от 0 до 10 | 6 | 8 |
Скорость реализации связанных задач | Часы на задачу | 10 | 6–8 |
Скорость обработки стандартного текста на 1000+ символов | Миллисекунды | 2500 — 4000 | 1000 — 2000 |
Количество уязвимостей | Количество CVE (уязвимостей) | 3 | 0 |
Задача была оценена в 20 часов разработки. Благодаря тому, что мы использовали понятные представителям бизнеса метрики, мы с легкостью доказали, что выгода от выполнения задачи превысит затраченное время.
Итоги
Я подробно поделилась своим опытом, чтобы статья была по‑настоящему полезной. На первый взгляд, система может показаться сложной, но на деле главное — начать. Вот что можно сделать уже сегодня:
Создайте документ на всю команду и назовите его «Технический бэклог».
Внесите туда три самые очевидные боли вашей вашего проекта.
Добавьте в этот документ задачу на аудит кода.
Покажите этот документ вашему руководителю или коллегам и обсудите, как можно выделить на это время.
Это будет первый шаг на пути к стабильной и надежной кодовой базе.
А какими подходами для управления техдолгом пользуетесь вы? Буду рада обсудить в комментариях.
