Видалення 19 000 рядків мертвого коду компілятора без сліпої довіри до штучного інтелекту
Інженер видалив близько 19 000 рядків мертвого коду компілятора за тиждень без жодної регресії, поєднавши великі мовні моделі з перевіркою статичних графів викликів. Методологія ділить код на чотири категорії ризику та використовує тимчасові тести.
Чому це важливо
Ви можете безпечно виконувати масштабні рефакторинги застарілого коду, обмежуючи контекст LLM статичним аналізом та верифікуючи видалення через детерміновані графи викликів.
TL;DR
- 01Не доручайте LLM глобальний пошук мертвого коду; спочатку детерміновано простежте залежності через clangd та compile_commands.json.
- 02Класифікуйте кожен фрагмент за категоріями ризику (Mechanical, Cross-ownership, Side effects, Surgery) до початку правок.
- 03Пишіть тимчасові тести на видалення, які перевіряють повну відсутність старих символів перед початком модифікації коду.
Ключові факти
- Видалено коду
- ~19 000 рядків
- Час виконання
- Близько 1 тижня
- Регресій у продакшені через 1 місяць
- 0
- Категорії класифікації
- Mechanical deletion, Cross-ownership, Side effects, Surgery
Ліквідація контекстного податку мертвого коду
Застарілий код створює додаткові накладні витрати в епоху ШІ-розробки: моделі сприймають списані патерни як легітимні зразки та відтворюють їх у нових PR. Видалення 19 тисяч рядків коду компілятора без регресій вимагає чіткого розмежування детермінованих інструментів і ймовірнісних суджень LLM.
Обмеження контексту статичним аналізом та маркуванням
Замість передачі всього репозиторію в модель, процес розпочали з аналізу прапорця --XYZ через compile_commands.json. Модель розмітила викликані функції двома мітками:
RED: поведінка безпосередньо залежить від значення прапорця.BLUE: функція лише прокидає або формує конфігураційні дані.
Щоб уникнути пропущених динамічних викликів без сліпої довіри до LLM, із тієї самої точки входу запускали додатковий інструмент аналізу графів викликів. Збіг результатів підтверджував повноту охоплення.
Чотирирівнева класифікація ризиків
Кожен виявлений вузол розподілили за категоріями, які визначали стратегію тестування: 1. Mechanical Deletion: Повністю недосяжні блоки коду, які перевірялися тестами на відсутність символів. 2. Cross-Ownership: Інтерфейси на межі володіння іншими командами, ізольовані через патерн Adapter. 3. Side Effects: Функції з мутацією глобального стану. Такі ділянки редагувалися розробником вручну. 4. Surgery: Заплутані функції зі збереженням робочих гілок, які розділялися під контролем хірургічних тестів.
Спробуй за 2 хвилини
// RED, MECHANICAL-DELETION: reached only through the flag's branch.
void addFlowXPasses(PassManager &pm);
// RED, SURGERY: keep default branch, excise retired branch.
void buildPipeline(PassManager &pm, const PipelineConfig &cfg);cpp
✓ Коли використовувати
- Очищення багатотисячних блоків технічного боргу та виведених з експлуатації прапорців у системних проєктах.
- Ситуації, коли ШІ-асистенти продовжують галюцинувати видаленими API та старими патернами у нових пул-реквестах.
✕ Коли НЕ варто
- Невеликі рефакторинги, де неробочий код обмежений одним файлом без побічних ефектів.
- Динамічні мови програмування, де рефлексія повністю приховує графи викликів від інструментів статичного аналізу.
Що зробити сьогодні
- Згенеруйте compile_commands.json для вашого C++ або системного репозиторію для відстеження ієрархії викликів перед рефакторингом.
- Створіть тимчасові юніт-тести, які падатимуть, якщо застарілий прапорець конфігурації або символ усе ще присутній у збірці.
- Розділіть задачі рефакторингу для ШІ-агентів на прості механічні видалення та хірургічні редагування складних гілок.