让我们假设你正处于一个长期运行的项目中（长期运行=几年），正如预期的那样，全新版本将会出现一些问题。可能有一个新的.Net框架具有全新的功能（例如Linq，实体框架，WPF，WF ......），一个新的Visual Studio或你最喜欢的控制库的V.next，一个新的模拟框架和更多的东西。 您处理这些技术更新的准则是什么？您是立即采用它们还是在项目结束之前忽略它们？你对不同的东西（工具，框架，支持的东西）有不同的指导方针吗？
答案 0 :(得分：4)
根据我的经验，这些决定总是根据具体情况做出。考虑了几个因素，包括：
新技术有多成熟？该组织是否愿意使用最前沿的新技术处于最前沿，或者是否更愿意使用经过验证的工具和方法？
您的员工有哪些技能？它们是否与新技术的使用一致，还是需要更多的培训？提高生产率是否会超过加快速度所需的时间？
您对现有技术有何投资？转向新技术的成本是多少？代码涉及多少返工和重写？
有什么要求？它是否受现有技术支持，还是满足要求所需的新工具？
性能期望是什么？新技术是否提供了旧技术无法满足的性能改进？
技术文化怎么样？组织供应商是否具体（例如Microsoft商店）？可以使用开源代码吗？
该项目的范围是什么？它是一个大型项目，可以从框架和工具等支持技术中受益，还是一个小项目会被这些东西过度压缩和复杂化？
如何支持新技术？供应商是否有良好的文档？如果你有问题，有没有人可以和你交谈？或者你是一个拥有知道如何在没有支持合同的情况下解决问题的人的组织？
该技术是否适合使用？它似乎有意义吗？它干净而优雅吗？其他人似乎喜欢它吗？其他人有问题吗？
这项技术是本周最新的风格吗？它是否已在战场上证明自己能够产生切实的结果，还是仅仅是一种宗教？
您需要花多少时间学习新技术并解决问题？这些好处是否超过了成本？
作为一个非常简短的例子，我为我最近的项目选择了Link to SQL，因为该项目足够复杂以保证ORM，L2S表现良好且轻量级，我们是微软商店，我的感觉是实体框架还没有为黄金时间做好准备（尽管微软表示它将成为未来的首选框架）。
答案 1 :(得分：3)
坚持你的开始。
一个庞大而长期运行的项目通常会带来庞大而高度复杂的代码库。对库的新版本进行任何更改或升级都会以非常微妙和意想不到的方式添加错误。
另外：对于大型项目，所使用的工具和库应该在设计阶段进行测试和评估。除非您发现显示停止或安全问题，否则最好不要升级。
永远记住：不要在溪流中间换马。 ： - ）
答案 2 :(得分：1)
我想说的是不同的因素，比如 -
嗯，也可能有其他有说服力的因素。这些是我头顶的。我希望它有所帮助。
欢呼声
答案 3 :(得分：1)
如果您正在讨论特定于框架的示例，我将给您的最大建议是将系统和应用程序分开。这就是我喜欢模型 - 视图 - 控制器等模式的原因 - 它使您的代码保持模块化，这意味着您可以升级部分而不会破坏整个应用程序。
在更实际的层面上，如果您的框架有一个Git或SVN存储库，请从repo中检查通常的“system”目录，然后您可以偶尔调用'svn update'来跟上最新和最好的构建。< / p>
答案 4 :(得分：0)
我建议该项目不会持续那么久。每隔几个月迭代一次，以较小的部分开发应用程序。这样，随着新技术的出现，您可以随时进行必要的更改并实施更新，而不得不决定重新开发整个应用程序。正如你所说，尝试在事情发生变化时开发整个应用程序是行不通的。
答案 5 :(得分：0)
正如另一张海报所说，这肯定是个案的基础。您可以升级什么，何时升级主要取决于测试新版本系统的难易程度。为您的应用程序提供全面的自动化测试套件对此有很大帮助。
通常，我会尝试尽可能多地更新到库的最新稳定版本，因为这样可以使维护更容易。如果您不更新，您可能会发现自己正在修补或解决您正在使用的库版本中的错误。如果您更新频率较低，每次更新都会有更多工作，因为您需要处理更多更改，并且自上次触摸系统以来已经更长时间了，因此您对它的记忆较少。