Как удалить 19 тысяч строк мёртвого кода, не доверяя ИИ

Автор описывает, как примерно за неделю удалил из компилятора около 19 тысяч строк мёртвого кода и сократил бинарник более чем на 50 МБ. Спустя месяц — ни одного отката, ни одной правки-заплатки.

Почему удаление откладывают

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

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

Задача

Устаревший сценарий (назовём его X) управлялся опцией --XYZ. Он уже не лежал ни на одном пути по умолчанию, но был переплетён с живым кодом. Требовалось убрать всё до последнего следа и при этом не изменить поведение выживающих сценариев.

Пять шагов без доверия к модели

Область. Сначала — не как удалять, а что вообще нужно читать. От точки разбора флага статический анализ по compile_commands.json обходит всех вызывающих и вызываемых. Модель помечает каждую функцию цветом: КРАСНЫЙ — поведение зависит от флага, СИНИЙ — лишь передаёт его данные. Разметка проверяема: второй инструмент обхода графа вызовов должен дать тот же набор функций. Доверять ИИ не требуется.

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

Леса. Для каждой цели — тест, падающий, пока цель не достигнута. Тест на удаление сначала красный, после уборки — зелёный; забытое место остаётся красным. Эти тесты — строительные леса: их снимают по окончании работ.

Удаление и хирургия. Правки вносит ИИ по категориям, раунд за раундом. Сначала раунд смотрит субагент, затем — автор.

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

Итог

Удалено около 30 файлов и 19 тысяч строк, бинарник похудел на 50+ МБ. Тщательно просмотрено лишь около 12% удалённых строк — классификация подсказала, какие именно. Вывод автора прост: ИИ сделал почти всю работу, а он не доверился ни единому его шагу. Противоречия здесь нет: у каждого изменения был свой проверяющий — цвет, категория и тест, — и задачей человека было проверить проверяющих, а не переделывать работу заново.

Источник: Lobsters