我对人们提出的将保持向后兼容性所必需的所有笨拙逻辑与应用程序的主代码分开的策略感兴趣。换句话说，让您更接近于让您的代码看起来没有向后兼容性问题的策略，除了明显用于该任务的单独隔离源文件。
例如，如果您的应用程序读取特定的文件格式，而不是一个巨大的喇叭文件解析函数，您可以让您的代码首先迭代“怪癖”条目/对象的列表，其中每个怪癖检查文件以查看它是否是文件它将适用于，如果是这样调用它自己的解析逻辑而不是正常的案例逻辑。
Quirks 是一种不错的策略，但是您必须努力在应用程序中的所有适当位置放置用于进行 quirks 检查的钩子，并且检查的外观会因不同的 quirk 类型等而有所不同。似乎应该有专门为此任务提供样板的库。另一个问题是如何强制执行怪癖不被滥用为通用挂钩到应用程序的任意块。
我通常的策略是有一些单独的东西将向后兼容性输入转换为新的实现输入，然后将新的实现代码与这些转换后的数据一起使用。
这将取决于所述向后兼容性功能退役之前的时间范围。如果你相当确定在几个月后你将发布另一个版本的软件，不再需要这些怪癖，你可以保留旧代码，如果你有足够的自律去实际删除下一个开发周期中的所有杂物。我在我工作的地方维护两个独立的后端服务器组件，虽然它们不能同时升级，但它们通常可以在几周内相互升级。这意味着它们之间的通信需要向后兼容，但只能向后兼容一个版本，并且在每个版本中，我都可以删除我在前一个版本中出于向后兼容性原因留下的旧代码。
但是，如果兼容性层存在很长时间甚至无限期地存在（想想 Word 的二进制文件格式），我会尝试重构代码，使新功能和旧功能在其中处于同等地位。我认为旧格式（或行为）和新格式都是系统要求的一部分，旧格式没有理由成为其中的二等公民（除了旧的，即双关语）。