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

Question

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

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

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

Answer 1

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

Answer 2

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

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