Мне поручено поддерживать скромно большую систему (~ 60 тыс. LOC не-Moose OO Perl). Я начинаю сомневаться в мудрости рефакторинга, а не переписывать его. Я знаю, что этот вопрос обсуждался подробно, но ситуация необычайно сложна и имеет несколько элементов, которые указывают на противоположные стороны, поэтому мой вопрос. Извините за многословие вопроса; это было настолько кратким, насколько я мог справиться, получив всю картину.
По мере того, как система стоит, абстракции довольно плохи при инкапсулировании чего-либо чисто, о чем свидетельствует частая зависимость от действия на расстоянии, обильное использование блоков if/else с интимным знанием объектов типа, не связанных с модулем под рукой, и график зависимости, который выглядит как социальная сеть. Это, я чувствовал, было плохо, но может быть реорганизовано.
Тестовое покрытие является пятнистым. Это, конечно, исправление и должно быть исправлено перед рефактором. Разумеется, в такой системе тесты нуждаются в абсурдных количествах лесов, что делает улучшение тестового покрытия более трудным, но все же это вряд ли возможно.
И поэтому я планировал потратить много времени, медленно принося некоторый заказ хаосу. Я считаю, что трудно, но выполнимо, и система работает достаточно хорошо для деловых целей, несмотря на все это, поэтому она должна делать что-то правильно. И "все знают" переписывание чего-то вроде этого - рецепт катастрофы.
Но недавно я обнаружил, что некоторые из наиболее важных и плохо написанных частей системы имеют глубоко укоренившиеся и серьезные ошибки дизайна, которые полностью заходят в схему данных. Вся методология имеет серьезные проблемы (это консенсус среди тех, кто работал над этим, а не только я), и обходные пути для этого, вероятно, составляют половину кода в этой части, хотя он так плохо написан, что нет никакой надежды сказать им отдельно от бизнес-логики. Код слишком запутан для меня (я работаю над ним всего несколько месяцев) или предыдущий основной помощник (несколько лет), чтобы понять его полностью. Он также имеет покрытие менее 10%.
Никто не уверен, что они могут полностью и правильно описать, что выполняет эта часть, а тем более - как. Получение хорошего тестового покрытия для этой части практически невозможно, если код не поддается анализу, а требования, которые он удовлетворяет, недостаточно изучены. Рефакторинг без тестового покрытия является неправильным, и он не является удаленным практическим в такой размерности, сложности, с такими распространенными проблемами (и динамически типизированное делает невозможным автоматическое обнаружение последствий изменения).
Если оставить этот и темные углы нетронутыми, это не вариант из-за постоянно меняющихся бизнес-требований.
Единственный практический выход из этого, который я вижу, начинается с переопределения системных требований на бизнес-уровне и принятия обязательства выполнить эту спецификацию и рискнуть любой поломкой, которую никто не ожидал. Я знаю, что это плохая стратегия, но я не вижу альтернативы. Если это выбрано как путь вперед, кажется, что многое из рефакторинга выходит из окна, что оставляет мне серьезный вопрос о достоинстве даже попытки реорганизовать это.
Это приводит меня к конкретному вопросу: рефакторинг плохой стратегии в этом случае? Ответы, подтвержденные реальным опытом, очень предпочтительны, поскольку я думаю, что теоретические аспекты хорошо установлены здесь и в других местах.
