保持jQuery最新的实用方法？
我们正在研究的一些项目在jQuery 1.4.2或更早版本中有很强的根源，并且在缺乏最新版本的性能优势（或语法糖），使用现已弃用的方法的羞辱以及使用它们的不适之间部署3年以上版本的积极维护的库，现在迫在眉睫。
社区中流行的一些做法是我们可以采用/重新访问以确保顺利推出（即关注模糊的兼容性问题，获取全局回归，重新考虑一些旧代码……）？ 它们如何最好地集成到SDLC中以便将来升级？ 什么是jQuery等库的合理升级时间表（我预计每次发布时都不会有显着的收益或合理的成本，但每6-12个月一次可能是合理的）？
要真正回答你的三个问题，这里有一些我已经完成或至少建议的事情：
平稳升级部署的最佳实践
- 有测试。 这些可以是JS和/或浏览器测试的unit testing。 这些应该至少涵盖项目中使用的最典型和最复杂的function。 如果您没有测试，请编写它们。 如果您不想编写测试，请重新考虑。 如果你真的不想编写测试，至少要有一个用户可以手动执行的用例列表。
- 确保在升级之前通过所有测试。
- 阅读您现在使用的版本与最新版本之间的每个 （主要）版本的发行说明。 另请参阅API文档中的已 删除和已弃用类别。 如果您的任何代码使用jQuery UI，请查看插页式版本的发行说明和升级指南 。 在执行此操作时，请记下您可能必须在代码库中更改的内容（可能会大量使用
grep）。 - 如果您项目的当前jQuery版本> = 1.6.4，还可以考虑使用jQuery Migrate插件来进一步评估所需的工作。
- 根据实现目标所需的工作，您的项目是否使用任何需要特定版本jQuery的第三方库，其他因素，您可以考虑等，确定您希望成为升级目标的版本。
- 与您的团队会面，查看要对您的代码库进行的更改列表，并相应地划分/分配工作。 也许写一些脚本或其他工具来帮助。 如果您有，那么您的团队的编码风格指南/最佳实践文档可能也需要更新。 决定一次性（推荐）或滚动更新版本，如果可能的话+可取的。 想出一个合适的发布策略。 （我建议不要将升级作为代码库中另一个无关的大更改的一部分发布，因此如果需要，可以轻松回滚。）
- 在整个升级过程中，不断运行测试。 手动测试时，请始终监视浏览器控制台是否存在新错误。 编写涵盖意外错误的新测试。
- 当所有测试通过时，决定你想要如何推出 – 如果它是一个站点，所有用户一次或一次百分比，等等。对于一个库或其他项目，也许你会发布一个beta /前沿你可以让更有野心的用户在野外为你测试的版本。
- 记录您刚才所做的一切，以便下次更容易。
- [利润。]
如何将升级集成到正常的工作流程中
- 再次，测试。 确保你拥有它们。 确保它们很好，维护并覆盖了大部分代码库和用例。 强烈建议使用持续集成设置来自动运行这些测试。
- 考虑让您的团队创建并同意遵循编码风格指南或标准。 这将使将来更容易搜索已弃用的函数调用或构造，因为每个人都会遵循类似的编码模式。 诸如脚本，提交挂钩，静态分析工具等工具来强制执行或嗅出错误的编码风格可能是有用的（取决于团队）。
- 调查并决定使用像NPM或bower这样的包管理器来管理jQuery版本和您可能使用的依赖它的其他第三方库。 （您仍然需要维护自己的JS代码并完成与上面相同的过程。）
- 再次，一旦您超过1.6.4版，请确保迁移插件是升级工作流程的一部分。
- 评估从最初的大型升级过程起什么作用，什么不起作用，并从中提取最适合您当前工作流程的一般过程。 无论您是否计划每次有新版本升级，都会有持续的维护任务和习惯，您可能希望将其作为一般开发最佳实践保留。
合理的升级时间表
这基本上是一个CBA /风险管理问题。 你必须权衡一些事情：
- 在同一主要版本中应该没有重大的API更改，因此您通常应该能够以最小的努力升级到最新的次要版本，不需要重构。 这假设您已经拥有并维护了良好的测试，您可以在项目确定所有测试完成之前就可以在项目上运行。
- 主要版本升级需要更多研究，更多重构和更多测试。 在研究步骤之后，您应该进行升级的成本效益分析。
- 这可能并不重要，但如果您的任何项目是一个拥有许多用户的网站，那么下次访问它时，所有用户必须下载基本上所有已更改的JS文件的成本是多少（而不是坚持可能仍在其浏览器中缓存的旧版本）？
- 升级的决定应始终是主观的。 无论是次要的还是重大的，您每次都需要certificate升级是否值得。 请务必阅读发行说明。 它是否修复了安全漏洞或与您或您的用户当前遇到的问题相关的错误？ 它会显着提高项目的性能（确保有基准来稍后validation）吗？ 它是否大大简化了您一直使用的编码模式，使您的代码更清晰，更容易编写？ 是否有您想要使用的第三方库依赖于这个较新的版本？ 您是否已经使用了依赖于旧版本的第三方库？ （如果是这样，这些库是否可能很快升级以使用较新版本？）您是否对测试和QA流程有信心，升级将需要合理数量的开发资源并且不会导致重大回归？ 您是否正在考虑最终用其他东西切换jQuery？ 等等。
当然这只是我的建议。 其中有一些反复出现的主题，我希望它们很清楚。 无论如何，我希望有人觉得这很有帮助！
你永远都会过时。 一旦你完成了对最新版本的更新，几个月之后就会出现一个更新的版本。
除非您愿意花费数小时/数天/周的开发，测试和错误修正，并且可能会破坏面向用户的function，否则您不应仅仅使用最新方式声明事件处理程序进行更新。 它不会伤到你。 通常这是一件冒险的事情。 这转化为开发团队成本。 你已经知道了。 重构，特别是当项目没有明显风险时，通常难以为管理者辩护。 你应该仔细检查你的想法，以确保在已经工作的代码中使用新的jQuery会有什么不同。
现在，如果您正在创建现有站点中的新页面，则可以在这些区域中包含新版本。 但是，这将产生一个结果：假设您和您的团队除了开发网站的新部分外，还必须维护使用旧部分的部分。 每个人都需要知道他们正在编写代码的jQuery的特定版本。
所以，要结束，我会说这样的话。 除非由于旧的jQuery版本而导致项目被推迟或在技术上被阻止存在真正合理的风险，否则您将因为破坏已经正在运行的东西而陷入困境，并且需要花费额外的时间来制作所有内容工作以及之前的工作。
无论如何，这种方法并不意味着您可以开始将“新部分”与旧部分分开，并使用新区域中的最新库。
这值得研究： https ： //github.com/jquery/jquery-migrate/#readme
此插件可用于检测和恢复已在jQuery中弃用并从1.9版开始删除的API或function。 有关插件生成的消息的详细信息，请参阅警告页面 。 有关jQuery 1.9中所做更改的更多信息，请参阅升级指南和博客文章 。
Twitter的人很好地解决了这个问题。
http://github.com/twitter/bower
它完成了它在锡上所说的内容 – 它是Web的包管理器（包括保持JQuery等JS文件的最新版本）
为了在开发树中保持最新，我建议使用src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js" （完整的未缩小版本，允许使用更容易调试）
然后当你去发布时，只需将其替换为标题注释中的特定缩小版本（目前http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js ）有更好的客户端缓存和使用别人的带宽的好处。
如果缓存不是一个问题，而是确保它会自动获得该次要版本的错误修正，您可以只使用主要版本和次要版本，例如： http ： //ajax.googleapis.com/ajax/libs/jquery/1.9 /jquery.min.js （注意：谷歌尚未推出1.9系列;但1.8系列高达1.8.3）由于这些版本定期更新以修复错误，因此不会像特定版本那样进行缓存发布
在这个时代，我们无法预测任何软件版本的稳定性。 几年之后软件和服务版本在一年或两年后发布。 但此时服务的版本正在快速而频繁地更新。
因此，如果您在服务中使用任何服务，则必须使用敏捷开发 。 通过这种开发方法，您可以轻松地更改新要求并根据您更改所需的方法。
请不要使用折旧方法，因为它们不适合长期服务版本。 并使用其他服务创建您自己的服务函数库的已使用服务的库，以便您可以根据新版本轻松更改它们。
例如 ：就像你有一个方法名称update_var(); 它正在调用其他服务的另一种方法，如$a = newlib::check_update(); 。 然后通过创建库，您必须更改您的函数的主库以及所涉及服务的核心库