Промт для рефакторинга легаси-кода: от спагетти до чистой архитектуры
Соблазн понятный: скормить модели тысячестрочный файл и попросить переписать красиво. Результат тоже понятный — красивый код, который делает не то же самое. В легаси всегда есть поведение, о котором никто не помнит, и оно кому-то нужно: обработка кривого формата от старого клиента, обход бага в библиотеке, тихое приведение типов, на которое завязан отчёт.
Поэтому порядок обратный: сначала зафиксировать текущее поведение, потом менять форму, не трогая смысл.
Шаг 1. Понять, что код делает
Вот функция из легаси-проекта. Не предлагай улучшений. Объясни: 1. Что она делает — по шагам, на языке предметной области, а не на языке кода. 2. Какие у неё входы, включая неявные: глобальные переменные, состояние объекта, файлы, окружение, время. 3. Какие побочные эффекты: что она пишет, отправляет, меняет. 4. Какие ветки выглядят как обработка редких, но реальных случаев. 5. Что выглядит мёртвым кодом, и по какому признаку это можно проверить. КОД: [вставить]
Пункт про неявные входы обычно даёт неприятный сюрприз: функция, которая по сигнатуре принимает два аргумента, на деле зависит ещё от четырёх вещей.
Шаг 2. Характеризующие тесты
Это тесты, которые фиксируют поведение как есть, включая странности. Их задача не проверить правильность, а поймать момент, когда рефакторинг что-то изменил.
Напиши характеризующие тесты для этой функции. Задача — зафиксировать текущее поведение, даже если оно кажется неправильным. Покрой: типичный вход, каждую ветку условий, каждый ранний выход, поведение при пустом и некорректном входе. Если поведение выглядит как баг — всё равно закрепи его тестом и пометь комментарием «поведение под вопросом». Для неявных зависимостей предложи минимальный способ их подставить, не переписывая функцию.
Шаг 3. Разбор на части
Теперь предложи разбить функцию на части. Условия: - каждый шаг — отдельное, самостоятельно работающее изменение; - после каждого шага код компилируется и тесты проходят; - шаги упорядочены от самого безопасного к самому рискованному; - ни один шаг не меняет поведение. Для каждого шага: что делаем, почему это безопасно, какой тест это подтвердит. Начни с выделения чистых вычислений — без ввода-вывода и без состояния. Отдельно назови изменения, которые нельзя сделать безопасно, и что нужно сделать до них.
Требование маленьких шагов — не педантизм. Большой рефакторинг, сломавший поведение, невозможно отладить: непонятно, какое из тридцати изменений виновато.
Порядок, который работает
- Зафиксировать поведение тестами.
- Вынести чистые вычисления в отдельные функции.
- Сделать неявные зависимости явными — передавать параметрами.
- Разделить чтение данных, вычисление и запись.
- Дать осмысленные имена — теперь их видно.
- И только теперь обсуждать архитектуру.
Пункты 2 и 3 дают больше всего пользы за единицу риска. Часто после них необходимость в «чистой архитектуре» отпадает: код становится читаемым и без неё.
Ограничения модели на легаси
| Ограничение | Следствие |
|---|---|
| Видит только переданный фрагмент | Не знает, кто ещё вызывает эту функцию |
| Не знает истории | Примет обход бага за лишний код |
| Не различает мёртвый и редкий код | Предложит удалить нужное |
| Оптимистична к рискам | Назовёт безопасным то, что таковым не является |
Отсюда правило: прежде чем удалять что-либо по совету модели, ищите вызовы по всему проекту сами. И проверяйте логи: ветка, которая срабатывает раз в квартал, в логах видна, а в коде выглядит мёртвой.
Когда не рефакторить
Если код работает, никто его не трогает и менять там ничего не планируется — оставьте. Рефакторинг оправдан там, где вы собираетесь вносить изменения: он окупается будущими правками. Приводить в порядок код, к которому не вернутся, — трата времени с ненулевым риском что-нибудь сломать.