如何将向后兼容的代码与主代码清晰地分开？
我感兴趣的是人们提出了哪些策略来分离维持应用程序主代码的向后兼容性所需的所有糟糕逻辑。换句话说，这些策略可以让您的代码看起来更接近于不存在向后兼容性问题，除了专门针对该任务的单独隔离的源文件之外。
例如，如果您的应用程序读取特定的文件格式，而不是一个巨大的文件解析函数，您可以让代码首先迭代“怪异”条目/对象的列表，其中每个怪异检查文件以查看它是否是一个文件它将适用于，如果是这样，则调用它自己的解析逻辑而不是正常的情况逻辑。
怪癖是一个不错的策略，但您必须在应用程序中的所有适当位置放置用于怪癖检查的钩子，并且检查的外观会因不同的怪癖类型而异，等等。看起来似乎应该有专门用于此任务的样板的库。另一个问题是如何强制确保怪癖不会被滥用为通用目的挂钩到应用程序的任意块中。
I'm interested in what strategies people have come up with for separating all the crufty logic that's necessary to maintain backwards compatibility from the main code of an application. In other words, strategies that let you come closer to having your code look as if there were no backwards compatibility concerns except for separate isolated source files distinctly for that task.
For example, if your application reads a particular file format, instead of one giant honking file parsing function, you could have your code first iterate a list of "quirks" entries/objects, where each quirk checks the file to see if it's a file it would apply to, and if so invokes its own parsing logic instead of the normal case logic.
Quirks is an OK strategy but you have to do work to put hooks in for quirks checks at all the appropriate places in your app, and what the checks will look like will vary for different quirk types, etc. It almost seems like there should be libraries dedicated to the boilerplate for this task. Another issue is how to enforce that quirks aren't abused as general purpose hooks into arbitrary chunks of the app.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我通常的策略是使用单独的东西将向后兼容性输入转换为新的实现输入，然后将新的实现代码与此转换后的数据一起使用。
My usual strategy is to have something separate that will translate the backward compatibility input into the new implementation input, and then use the new implementation code with this translated data.
这将取决于所述向后兼容性功能停用之前的时间范围。如果您相当确定在几个月内您将发布软件的另一个版本，而该版本将不再有这些怪癖，那么如果您有足够的纪律来实际删除旧代码，则可以保留旧代码下一个开发周期中的所有问题。我在工作中维护两个独立的后端服务器组件，虽然它们不能同时升级，但它们通常可以在几周内升级。这意味着它们之间的通信需要向后兼容，但只能向后兼容一个版本，并且在每个版本中，我可以删除出于向后兼容性原因在上一个版本中留下的旧代码。
然而，如果兼容性层会保留很长时间甚至无限期（想想Word的二进制文件格式），我会尝试以这样的方式重构代码，使新功能和旧功能在其中处于同等地位。我认为旧格式（或行为）和新格式都是系统要求的一部分，并且旧格式没有理由成为其中的二等公民（除了旧格式，即双关语）。
This would depend on the time-frame until the retirement of said backwards compatibility features. It you're fairly sure that in a couple of months you're going to release another version of your software that will no longer have to have those quirks, you can just keep the old code around if you're disciplined enough to actually remove all the cruft in the next development cycle. I'm maintaining two separate backend server components where I work and while they can't be upgraded at the same time, they usually can be within a couple of weeks of each other. This means the communication between them needs to be backwards compatible, but only a single version back, and in each version I can remove the old code that I left for backwards compatibility reasons in the previous version.
If however, the compatibility layer is there to stay for a long time or even indefinitely (think Word's binary file formats) I would try to refactor the code in such a way that the new functionality and the old functionality are on equal terms in it. I think both the old format (or behavior) and the new format are part of the system's requirements and there's no reason for the old format to be a second class citizen in it (other than being old that is, pun intended).