Почему «неиспользуемый» код трудно признать мёртвым
Редактор может показать, что на функцию нигде не ссылаются, а поиск по проекту — что имя класса не встречается. Но приложение иногда находит нужный код не через обычный вызов. Имя класса может храниться в конфигурации, модуль — подключаться как плагин, а обработчик — вызываться по имени, собранному во время работы программы. Такие механизмы не всегда видны инструментам, которые ищут прямые связи между строками.
Есть и зависимость другого рода: код может быть нужен не самой программе, а окружению. Скрипт сборки, сторонняя интеграция или старая автоматизация способны запускать файл, о котором команда уже забыла. Удаление тогда проявится не при запуске приложения на компьютере разработчика, а в редком сценарии у пользователя.
Как риск делают проверяемым
Обычно подозрительный участок сначала ищут по нескольким признакам: нет прямых вызовов, он не попадает в обычную сборку, а тесты не проверяют связанную с ним функцию. Затем проверяют конфигурации, точки входа — места, откуда система начинает выполнение, — и правила подключения модулей. Если уверенности всё равно нет, код можно удалить отдельным изменением и внимательно наблюдать за проверками и ошибками в работающей системе.
Это не гарантирует, что всякая забытая зависимость обнаружится сразу. Поэтому большие удаления дробят: если после одного изменения что-то ломается, легче понять, какой именно участок был важен. Цена осторожности — лишняя сложность в проекте; цена поспешности — поломка, которую трудно воспроизвести. Именно эта асимметрия и превращает уборку кода в работу по проверке предположений, а не в обычное стирание ненужных строк.
