Я дам вам наш досвід рефакторингу LedgerSMB. Ми прийняли рішення робити щось по-різному і все ще робимо саме те, що ви описуєте, але без великої кількості методів клею (у нас є кілька методів склеювання btw, просто не багато).
Життя з двома кодовами
LedgerSMB протримався з двома кодовими базами близько 5 років, і це буде ще декілька, перш ніж стара база коду буде усунена. Стара база коду - це справжній жах. Неправильний дизайн db, Perl створює, як IS->some_func(\%$some_object);
поряд з кодом, який точно показує, чому метафора спагетті іноді використовується (шляхи виконання, що меандрують між модулями і назад, і між мовами, без рими чи причини). Нова база коду уникає цього, переміщуючи db-запити у збережені процедури, маючи більш чисту структуру для обробки запитів та багато іншого.
Перше, що ми вирішили зробити, - це спробувати переробляти модуль за модулем. Це означає переміщення всієї функціональності в певній області в новий модуль, а потім підключення старого коду до нового модуля. Якщо новий API чистий, це не велика справа. Якщо новий API не все стає волохатим, це запрошення попрацювати над новим API ....
Друга річ - багато випадків, коли новий код повинен мати доступ до логіки у старому коді. Цього слід уникати настільки, наскільки це можливо, оскільки це призводить до некрасивих методів склеювання, але не завжди можна цього уникнути. У цьому випадку клейові методи повинні бути зведені до мінімуму і уникати, наскільки це можливо, але застосовуватися при необхідності.
Щоб зробити цю роботу, вам потрібно взяти на себе зобов’язання переписати всю функціональність у певній області. Наприклад, якщо ви можете, наприклад, переписати одразу весь код відстеження інформації про клієнтів, це означає, що з кодом, який викликає це зі старого коду, не важко працювати, і відправка на старий код з нового коду зведена до мінімуму.
Друга річ полягає в тому, що якщо у вас є розумні абстракції на вашому місці, ви повинні мати можливість вибрати, на якому рівні API зателефонувати, і як зберегти це в чистоті. Однак вам слід подумати над тим, щоб переписати частини, які викликають ваш API, щоб вони також були чистішими.
Існує багато напрямків бізнес-інструментів, які є невідмінно складними. Ви не можете позбутися всієї складності. Але ви можете керувати ним, орієнтуючись на чисті API, які конкретно роблять те, що вам потрібно зробити, і модулі, які конструктивно використовують цей API. Клей повинен бути крайнім засобом лише після врахування, що перезапис решти викликового коду може пройти швидше.