Долг в наследство. Часть 6: об искусстве маленьких шагов в бездну техдолга Экспедиция в техдолг может показаться безнадёжной. Но слона едят по кусочкам — построив алгоритм и следуя ему, решить эту задачу проще. Важное уточнение. Алгоритм работает в больших студиях, где время на работу с техническим долгом выделяется системно. Но в любом случае алгоритм логичен, эффективен и заслуживает усилий даже со стороны небольших студий внедрять себя хотя бы постепенно. Это завершающий пост в нашем цикле про техдолг. Все посты доступны по тэгу #долгвнаследство, а в статье, собранной на базе этих публикаций, будет побольше кейсов. Итак, алгоритм работы с техдолгом: 🔭 Этап 1: Разведка 1.1 Поиск носителя знаний. Найти в истории репозитория последнего активного разработчика и постараться связаться с ним, чтобы узнать подводные камни и историю решений. 1.2 Локальный запуск. Клонировать проект, попытаться запустить его локально и зафиксировать все ошибки сборки/запуска для оценки масштаба проблем. 1.3 Анализ зависимостей. Проверить манифесты на предмет устаревших и уязвимых пакетов, определить, что можно обновить без изменения кода. 1.4 Архитектурный осмотр. Бегло просмотреть код, чтобы понять стиль, использованные паттерны и общую структуру проекта. 🗺 Этап 2: Стратегия 2.1 Определение границ – Чётко обозначить, какую функциональность нужно изменить, а какая должна остаться нетронутой; выделить критические участки. 2.2 Быстрые победы – Выполнить безопасные обновления зависимостей (patch‑версии) и закоммитить их отдельно, чтобы сразу снизить технический долг. 2.3 Составление плана обновлений – Разработать поэтапную дорожную карту приведения проекта к современным стандартам. 2.4 Согласование – Представить план руководству, объяснить риски и выгоды, получить одобрение на временные затраты. 🛡 Этап 3: Защита 3.1 Документирование поведения. Написать характеризационные тесты (characterization tests), которые фиксируют текущую работу ключевых функций до их изменения. 3.2 Автоматизация проверок. Внедрить линтеры и форматтеры для изменяемых файлов, чтобы обеспечить единый стиль кода. 🛠 Этап 4: Рефакторинг 4.1 Правило бойскаута. При внесении правок улучшать только те участки, которые непосредственно затрагиваются (переименовывать переменные, выделять методы и т. д.). 4.2 Микро‑шаги. Делить изменения на максимально маленькие коммиты, каждый из которых легко откатить. 4.3 Тотальное тестирование. После каждого микро‑изменения прогонять тесты и сравнивать результат с эталонным поведением. 🌐 Этап 5: Внедрение 5.1 Код‑ревью. Обязательно проводить ревью всех правок, даже в легаси‑коде, чтобы поймать возможные ошибки. 5.2 Непрерывная интеграция. Настроить автоматический прогон тестов в CI при каждом коммите. 5.3 Постепенный выкат. Если возможно, применять feature flags или канареечные релизы для плавного развёртывания изменений на продуктивную среду. #долгвнаследство