何时将现有程序升级到新的语言功能？
假设您有一个用 Java 1.4 或 C# 1.0 编写的程序。当然，该程序不使用后续版本中引入的泛型和其他语言功能。
现在必须做出一些重要的改变。当然，您已经拥有更新的 IDE/编译器，因此您可以使用 Java 1.6 或 Java 1.6。改为 C# 3.5。您会利用这个机会升级到最新的语言功能，即使用通用容器并摆脱许多强制转换等。或者您会保持原样，仅将新功能用于新部分。或者甚至保留原来使用的版本的功能，以保持一定程度的一致性？
Imagine you have a program written e.g. in Java 1.4 or C# 1.0. Of course this program doesn't use generics and other language features that were introduced with later versions.
Now some non-trivial changes have to be made. And of course, you already have a newer IDE/compiler so you could use Java 1.6 resp. C# 3.5 instead. Would you use this oppurtunity to upgrade to the latest language features, i.e. use generic containers and get rid of many casts, etc. Or would you leave it like it is, and use the new features only for new parts. Or even stay with the features of the version originaly used, to maintain a level of consistency?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这里要考虑的一个因素是您当前和未来吸引和留住开发人员对使用过时技术构建的应用程序进行维护和支持的能力。许多经验丰富的开发人员在旧版本的 Java 和 C# 流行时都使用过它们，因此我们并不是没有经验。但是，如果我们在 .Net 1.0 上工作一年，我们就会忘记我们现在对后续版本的了解。虽然我们这一年都在研究旧技术，但我们所有的朋友和竞争对手都在磨练他们在最新技术上的技能。我们永远无法弥补那一年的遗憾。
除了落后之外，我们还会发现无法使用我们现在习惯使用的更高版本中的功能会非常令人沮丧。
因此，年轻的开发人员不会有旧技术的经验（.Net 1.0 于 2002 年 1 月发布）。年长的开发人员已经去过那里并且不想回去。
另一方面，如果您继续使用旧版本，您会对自己的技能感到满意。您不必花费大量时间来学习新技术。也许最重要的是，您将拥有工作保障。
One consideration here is your present and future ability to attract and retain developers to perform maintenance and support on an application built with outdated technology. Many seasoned developers worked with those older versions of Java and C# when they were current, so it isn't that we have no experience with it. But if we spend, say, a year working in .Net 1.0, we will be forgetting what we now know about subsequent versions. And while we are spending that year working in old technology, all of our friends and competitors are honing their skills on the latest technology. We will never be able to make that year up.
In addition to falling behind, we will find it intensely frustrating not to be able to use the functionality in the later versions that we are now comfortable using.
So, younger developers will not have had experience in older technology (.Net 1.0 was released in January 2002). Older developers have been there and don't want to go back.
On the other hand, if you stay back in the older version, you will be comfortable with your skillset. You won't have to spend a lot of time learning about newer technologies. And perhaps best of all, you will have job security.
尽可能保留工作代码。看起来代码应该全部使用最新的编程秘方，但是对于经过尝试和测试的代码有很多话要说。
我只会考虑重写在任何情况下都必须进行大量修改以添加新功能的代码，即使这样，我也只会更改编程隐喻，如果它会加快新功能的编写速度。
否则，您将不断地调试以前可以工作的代码，并消耗本可以用于改进产品的精力。
As far as possible, leave working code alone. It may seem like the code should all be using the latest programming secret sauce, but there is a lot to be said for tried and tested code.
I would only consider rewriting code that must be heavily modified in any case to add a new feature, and even then I would only change the programming metaphor if it will speed up the writing of the new feature.
Otherwise you will constantly be debugging code which was previously working, and using up energy that could have gone into improving the product.
这取决于。需要用旧的编译器来编译吗？你有足够的时间/金钱来改变一切吗？
It depends. Does it need to be compiled by old compilers? Do you have enough time/money to change everything?
从理论上讲，这是成本和收益之间的简单平衡，因此只有在收益大于成本时才应该进行重写。
问题在于，几乎不可能衡量实际成本（不仅是完成工作的成本，还有不做其他可能贡献更多的事情的成本）。一般来说，好处根本无法真正衡量——您只能猜测如果您继续使用旧代码，事情会有多困难。
这让我们几乎没有机会根据理性的衡量来做任何事情。这就留下了一个简单的经验法则：保留旧代码，直到您唯一的选择是重写它或完全放弃它。
In theory, it's a simple balance between costs and benefits, so you should only do the rewrite if the benefits outweigh the costs.
The problem with that is that it's almost impossible to measure the real costs (not only of doing the work, but of not doing other things that might contribute more). Generally speaking, the benefits can't really be measured at all -- you can only guess at how much difficult something would be if you'd stayed with the old code.
That leaves us with little chance to do anything based on rational measurements. That leaves a simple rule of thumb: leave old code alone until your only choices are to rewrite it or abandon it completely.
我的代码维护基本规则：如果它没有损坏，就不要修复它。
My basic rule for code maintenance: If it ain't broke, don't fix it.
这只是重构的一种特定形式，因此所有关于何时以及如何执行此操作的建议。
It's just one specific form of refactoring, so all the advice on when and how to do that applies.