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

В какой-то момент мы решили провести самоаудит собственного проекта. Не формальный, для отчёта, а реальный, чтобы понять, в каком состоянии находится кодовая база.

В результате мы увидели, что из 41 тысячи методов почти 36 тысяч система посчитала «неиспользуемыми». Формально это означало, что большая часть кода не участвует в работе продукта.

При этом продукт работал стабильно. Тесты проходили.

Возник разрыв между отчётом и реальностью.

Почему это важно для бизнеса

На уровне разработки такую ситуацию можно списать на «сырой инструмент». На уровне компании это уже риск.

Если система анализа показывает некорректные данные, руководство принимает решения на искажённой картине:

1. переоценивается объём технического долга
2. неправильно оценивается стоимость изменений
3. искажается приоритет задач
4. растёт зависимость от отдельных специалистов, которые «знают как на самом деле»

Формально контроль есть. По факту его нет.

Что показал самоаудит

Проблема оказалась не в коде, а в понимании кода.

Простой подход к поиску «мёртвых» функций не работает в современных системах:

1. часть логики вызывается через таблицы обработчиков
2. часть через механизмы динамического вызова
3. что-то через инфраструктуру фреймворков
4. часть скрыта во вложенных функциях и замыканиях

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

Каждая такая ошибка — это слепая зона.

Что изменилось после доработки анализа

Мы начали разбирать каждое ложное срабатывание как инцидент.

Если функция считается «мёртвой», но используется, значит анализ не видит часть реальных связей.

В результате:

1. переработан алгоритм определения связей между функциями
2. добавлены уровни фильтрации для исключения служебных сценариев
3. устранены ошибки, из-за которых терялись реальные вызовы

После нескольких итераций картина изменилась принципиально.

Из тысяч «подозрительных» функций остались десятки.Все они действительно не использовались.

Что это дало на уровне проекта

Эффект оказался не в цифре «сколько кода удалили».

Изменился сам контур управления.

1. Прозрачность структуры: появилось понимание, как реально связаны части системы, а не как это описано в документации.

2. Контроль изменений: перед доработками стало видно, какие участки затронет изменение и где есть риск побочных эффектов.

3. Снижение зависимости от людей: знание о системе перестало быть привязано к одному специалисту.

4. Корректный технический долг: вместо абстрактных оценок появился конкретный список проблемных мест.

Почему это нельзя заменить документацией

Документация отвечает на вопрос "почему система устроена так".Но она почти никогда не показывает, как она работает сейчас.

Код меняется ежедневно.Документы обновляются периодически.

Разрыв между ними является нормальным состоянием любой развивающейся системы.

Если компания опирается только на документацию, она управляет описанием, а не реальностью.

Практический вывод

Часть знаний о системе невозможно поддерживать вручную.

Её нужно извлекать напрямую из кода:

1. реальные зависимости
2. точки риска
3. структура вызовов
4. зоны высокой связанности

Без этого любые разговоры о качестве, безопасности и стоимости изменений остаются оценочными.

Проект КодГраф (codegraph.ru) — управленческий контур для анализа корпоративных кодовых баз.