Language agnostic 如何将向后兼容的代码与主代码完全分离？

我感兴趣的是，人们提出了什么策略来分离维护应用程序主代码向后兼容性所需的所有粗糙逻辑。换言之，这些策略使您的代码看起来更接近于没有向后兼容性问题，除了单独的独立源文件之外

例如，如果您的应用程序读取一种特定的文件格式，而不是一个巨大的文件解析函数，那么您可以让代码首先迭代一个“怪癖”条目/对象列表，其中每个怪癖检查文件是否是它将应用的文件，如果是，则调用自己的解析逻辑，而不是正常的大小写逻辑

---

怪癖是一个不错的策略，但是你必须在你的应用程序中的所有适当的地方设置用于怪癖检查的钩子，并且不同的怪癖类型的检查会有所不同，等等。似乎应该有专门用于此任务的样板的库。另一个问题是，如何确保怪癖不会被滥用，因为通用的钩子会钩住应用程序的任意块。

我通常的策略是使用一些单独的东西，将向后兼容性输入转换为新的实现输入，然后将新的实现代码与这些翻译后的数据一起使用。

这取决于所述向后兼容性功能失效之前的时间范围。如果你相当确定在几个月后你将发布你的软件的另一个版本，不再需要那些怪癖，你可以保留旧的代码，如果你足够自律，在下一个开发周期中真正去除所有的积垢。我在工作的地方维护两个独立的后端服务器组件，虽然它们不能同时升级，但通常可以在几周内彼此升级。这意味着它们之间的通信需要向后兼容，但只有一个版本需要向后兼容，在每个版本中，我都可以删除以前版本中出于向后兼容原因留下的旧代码

---

但是，如果兼容性层在那里停留很长时间甚至无限期（想想Word的二进制文件格式），我会尝试重构代码，使新功能和旧功能在其中处于同等地位。我认为旧格式（或行为）和新格式都是系统要求的一部分，旧格式没有理由成为二等公民（除了旧的，即双关语）。

+1：这通常也是我的方法。一个简单的包装器（用于代码）和格式转换器（用于数据）通常足以创建一个良好的兼容性层。这可能是最干净的策略，但如果您有大量数据，这可能会很棘手。然后我认为你会想要实现适配器视图而不是实际的转换，而在没有C++的反射语言中，这些分层可能是痛苦的。