Как Вы чисто разделяете код для назад совместимости от основного кода?
Я интересуюсь тем, что люди стратегий придумали для разделения всей неработоспособной логики, это необходимо для поддержания назад совместимости от основного кода приложения. Другими словами, стратегии, которые позволяют Вам прийти ближе к наличию Вашего кода, смотрят, как будто были не назад проблемы совместимости за исключением отдельных изолированных исходных файлов отчетливо для той задачи.
Например, если Ваше приложение читает конкретный формат файла вместо одной гигантской гудящей функции парсинга файла, у Вас мог быть свой код, сначала выполняют итерации списка записей/объектов "причуд", где каждая причуда проверяет файл, чтобы видеть, является ли это файл, это относилось бы и раз так вызывает свою собственную логику синтаксического анализа вместо нормального Case Logic.
Причуды являются стратегией OK, но необходимо сделать работу, чтобы вставить рычаги для проверок причуд во всех соответствующих местах в приложении, и на что будут похожи проверки, будет варьироваться для различных типов причуды, и т.д. Почти кажется, что должны быть библиотеки, выделенные шаблону для этой задачи. Другая проблема - то, как осуществить это, причудами не злоупотребляют, поскольку общая цель сцепляется в произвольные блоки приложения.
2 ответа
Моя обычная стратегия - иметь что-то отдельное, что переводит входные данные обратной совместимости в новые входные данные реализации, а затем использовать новый код реализации с этими переведенными данными.
Это будет зависеть от временного интервала до прекращения использования упомянутых функций обратной совместимости. Если вы совершенно уверены, что через пару месяцев вы собираетесь выпустить еще одну версию своего программного обеспечения, в которой больше не будет этих причуд, вы можете просто сохранить старый код, если вы достаточно дисциплинированы, чтобы фактически удалить весь мусор в следующем цикле разработки. Я обслуживаю два отдельных серверных компонента, на которых я работаю, и, хотя они не могут быть обновлены одновременно, обычно они могут находиться в пределах пары недель друг от друга. Это означает, что связь между ними должна быть обратно совместимой, но только с одной версией назад, и в каждой версии я могу удалить старый код, который я оставил для обратной совместимости в предыдущей версии.
Если, однако, уровень совместимости останется на долгое время или даже на неопределенный срок (подумайте о форматах двоичных файлов Word), я бы попытался реорганизовать код таким образом, чтобы новая функциональность и старая функциональность были на равных в этом. Я думаю, что и старый формат (или поведение), и новый формат являются частью требований системы, и нет никаких причин для того, чтобы старый формат был в нем второсортным (кроме того, что он старый, то есть каламбур).