Как вы четко отделяете код для обратной совместимости от основного кода?

Question

Мне интересно, какие стратегии придумали люди для отделения всей лживой логики, необходимой для обеспечения обратной совместимости с основным кодом приложения. Другими словами, стратегии, позволяющие вам приблизиться к тому, чтобы ваш код выглядел так, как будто не было проблем с обратной совместимостью, за исключением отдельных изолированных исходных файлов, отчетливо подходящих для этой задачи.

Например, если ваше приложение читает определенный формат файла, вместо одной гигантской функции разбора файла с гудком, вы могли бы сделать так, чтобы ваш код сначала перебирал список «причудливых» записей / объектов, где каждая из них проверяет файл, чтобы увидеть, это файл, к которому он будет применяться, и в этом случае вызывает собственную логику синтаксического анализа вместо обычной логики регистра.

Quirks - это нормальная стратегия, но вам нужно проделать работу, чтобы подключить хуки к проверкам причуд во всех подходящих местах в вашем приложении, и как будут выглядеть проверки, будет различаться для разных типов причуд и т. Д. Для этой задачи должны быть библиотеки, посвященные шаблону. Другая проблема заключается в том, как обеспечить, чтобы причуды не использовались как зацепки общего назначения в произвольные части приложения.

Answer 1

Моя обычная стратегия состоит в том, чтобы иметь что-то отдельное, что будет переводить ввод обратной совместимости в новый ввод реализации, а затем использовать новый код реализации с этими переведенными данными.

Answer 2

Это будет зависеть от периода времени до отмены указанных функций обратной совместимости. Если вы уверены, что через пару месяцев вы собираетесь выпустить еще одну версию вашего программного обеспечения, которая больше не будет иметь этих причуд, вы можете просто сохранить старый код, если вы достаточно дисциплинированы, чтобы фактически удалить все пустяки в следующем цикле разработки. Я поддерживаю два отдельных серверных серверных компонента, на которых я работаю, и хотя они не могут быть обновлены одновременно, они обычно могут быть в течение нескольких недель друг от друга. Это означает, что связь между ними должна быть обратно совместимой, но только одна версия обратно, и в каждой версии я могу удалить старый код, который я оставил по причинам обратной совместимости в предыдущей версии.

Если, однако, уровень совместимости существует надолго или даже на неопределенное время (подумайте о двоичных форматах файлов Word), я бы попытался провести рефакторинг кода таким образом, чтобы новые функциональные возможности и старые функциональные возможности были в равных условиях. в этом. Я думаю, что и старый формат (или поведение) и новый формат являются частью требований системы, и нет никаких оснований для того, чтобы старый формат был в нем второсортным гражданином (кроме того, что он старый, то есть каламбур).