我感兴趣的是人们已经提出了什么策略来分离维护向后兼容性和应用程序主要代码所必需的所有苛刻逻辑。换句话说，这些策略可以让您更接近于让代码看起来好像没有向后兼容性问题，除了明显针对该任务的单独的隔离源文件。
例如，如果您的应用程序读取特定的文件格式，而不是一个巨大的鸣笛文件解析函数，您可以让您的代码首先迭代一个“怪癖”条目/对象列表，其中每个怪癖检查文件以查看是否它是一个应用的文件，如果是这样的话，它会调用自己的解析逻辑而不是正常的案例逻辑。
Quirks是一个很好的策略，但你必须做一些工作，在你的应用程序的所有适当位置插入钩子进行怪癖检查，并且对于不同的怪癖类型等，检查看起来会有所不同。这几乎看起来像应该有专门用于此任务的样板库。另一个问题是如何强制将这些怪癖作为通用钩子滥用到应用程序的任意块中。
答案 0 :(得分：10)
我通常的策略是将单独的内容转换为将后向兼容性输入转换为新的实现输入，然后将新的实现代码与此转换后的数据一起使用。
答案 1 :(得分：0)
这将取决于所述向后兼容性功能退出之前的时间范围。你可以肯定的是，在几个月内你将发布另一个版本的软件，不再需要这些怪癖，你可以保留旧代码，如果你有足够的纪律来实际删除在下一个开发周期中所有的残余。我正在维护两个独立的后端服务器组件，在我工作的同时无法同时升级，它们通常可能在几周之内。这意味着它们之间的通信需要向后兼容，但只能返回一个版本，并且在每个版本中，我都可以删除我在之前版本中出于向后兼容性原因而留下的旧代码。
但是，如果兼容层可以保留很长时间甚至无限期（想想Word的二进制文件格式），我会尝试以新功能和旧功能相同的方式重构代码在里面。我认为旧格式（或行为）和新格式都是系统要求的一部分，并且没有理由将旧格式作为其中的二等公民（除了旧的，即双关语）。