保持jQuery最新的实用方法？

Question

我们正在研究的一些项目在jQuery 1.4.2或更早版本中有很强的根源,并且在缺乏最新版本的性能优势(或语法糖),使用现已弃用的方法的羞辱以及使用它们的不适之间部署3年以上版本的积极维护的库,现在迫在眉睫.

我们可以采用/重新访问社区中流行的一些实践,以确保顺利部署(即关注模糊的兼容性问题,获取全局回归,重新考虑一些旧代码......)？它们如何最好地集成到SDLC中以便将来升级？什么是jQuery这样的库的合理升级时间表(我预计每次发布时都不会有显着的收益或合理的成本,但每6-12个月一次可能是合理的)？

Answer 1

你永远都会过时.一旦你完成了更新到最新版本的更新,几个月之后会出现一个更新的版本.

除非您愿意花费数小时/数天/周的开发,测试和错误修正,并且可能会破坏面向用户的功能,否则您不应仅仅使用最新方式声明事件处理程序进行更新.它不会伤害你.通常这是一件冒险的事情.这转化为开发团队成本.你已经知道了.重构,特别是当项目没有明显风险时,通常难以为管理者辩护.你应该仔细检查你的想法,以确保在已经工作的代码中使用新的jQuery会有什么不同.

现在,如果您正在创建现有站点中的新页面,则可以在这些区域中包含新版本.但是,这将产生一个结果:假设您和您的团队除了开发网站的新部分外,还必须维护使用旧部分的部分.每个人都需要知道他们正在编写代码的jQuery的特定版本.

所以,关闭,我会说这样的话.除非由于更旧的jQuery版本而导致项目被推迟或在技术上被阻止存在真正合理的风险,否则您将因为破坏已经正在运行的东西而陷入困境,并且需要花费额外的时间来制作所有内容工作以及之前的工作.

无论如何,这种方法并不意味着您可以开始将"新部分"与旧部分分开,并使用新区域中的最新库.

Answer 2

要真正回答你的三个问题,这里有一些我已经完成或至少建议的事情:

平稳升级部署的最佳实践

• 有测试.这些可以是JS和/或浏览器测试的单元测试.这些应该至少涵盖项目中使用的最典型和最复杂的功能.如果您没有测试,请编写它们.如果您不想编写测试,请重新考虑.如果您reeeeally不想写测试,至少具有使用案例的列表会有人能够手动执行.
• 确保在升级之前通过所有测试.
• 阅读您现在使用的版本与最新版本之间的每个(主要)版本的发行说明.另请参阅API文档中的已删除和已弃用类别.如果您的任何代码使用jQuery UI,请查看插页式版本的发行说明和升级指南.在执行此操作时,请记下您可能必须在代码库中更改的内容(可能会大量使用grep).
• 如果您项目的当前jQuery版本> = 1.6.4,还可以考虑使用jQuery Migrate插件来进一步评估所需的工作.
• 根据实现目标所需的工作,您的项目是否使用任何需要特定版本jQuery的第三方库,其他因素,您可以考虑等,确定您希望成为升级目标的版本.
• 与您的团队会面,查看要对您的代码库进行的更改列表,并相应地划分/分配工作.也许写一些脚本或其他工具来帮助.如果您有,那么您的团队的编码风格指南/最佳实践文档可能也需要更新.决定一次性(推荐)或滚动更新版本,如果可能的话+可取的.想出一个合适的发布策略.(我建议不要将升级作为代码库中另一个无关的大更改的一部分发布,因此如果需要,可以轻松回滚.)
• 在整个升级过程中,不断运行测试.手动测试时,请始终监视浏览器控制台是否存在新错误.编写涵盖意外错误的新测试.
• 当所有测试通过时,决定你想要如何推出 - 如果它是一个站点,所有用户一次或一次百分比,等等.对于一个库或其他项目,也许你会发布一个beta /前沿您可以让更有野心的用户在野外为您测试的版本.
• 记录您刚才所做的一切,以便下次更容易.
• [利润.]

如何将升级集成到正常的工作流程中

• 再次,测试.确保你拥有它们.确保它们很好,维护并覆盖了大部分代码库和用例.强烈建议使用持续集成设置来自动运行这些测试.
• 考虑让您的团队创建并同意遵循编码风格指南或标准.这将使将来更容易搜索已弃用的函数调用或构造,因为每个人都会遵循类似的编码模式.诸如脚本,提交挂钩,静态分析工具等工具来强制执行良好或嗅出错误的编码风格可能是有用的(取决于团队).
• 调查并决定使用像NPM或bower这样的包管理器来管理jQuery版本和您可能使用的依赖它的其他第三方库.(您仍然需要维护自己的JS代码并完成与上面相同的过程.)
• 再次,一旦您超过1.6.4版,请确保迁移插件是升级工作流程的一部分.
• 评估从最初的大型升级过程起什么作用,什么不起作用,并从中提取最适合您当前工作流程的一般过程.无论您是否计划每次有新版本升级,都会有持续的维护任务和习惯,您可能希望将其作为一般开发最佳实践保留.

合理的升级时间表

这基本上是一个CBA /风险管理问题.你需要权衡一些事情:

• 这里应该是同一主要版本内没有破API的变化,所以你通常应该能够升级到最新的次要版本以最小的努力,无需重构.这假设您已经拥有并维护了良好的测试,您可以在项目确定所有测试完成之前就可以在项目上运行.
• 主要版本升级需要更多研究,更多重构和更多测试.在研究步骤之后,您应该进行升级的成本效益分析.
• 这可能并不重要,但是如果您的任何项目是一个拥有许多用户的网站,那么下次访问它时,所有用户必须下载基本上所有已更改的JS文件的成本是多少(而不是坚持可能仍在其浏览器中缓存的旧版本)？
• 升级的决定应始终是主观的.无论是次要还是重大,你每次都要证明升级是否值得.请务必阅读发行说明.它是否修复了您或您的用户当前遇到的问题的安全漏洞或错误？它是否会显着提高项目的性能(确保有基准来稍后验证)？它是否大大简化了您一直使用的编码模式,使您的代码更清晰,更容易编写？是否有您想要使用的第三方库依赖于这个较新的版本？您是否已经使用了依赖于旧版本的第三方库？(如果是这样,这些库是否可能很快升级以使用较新版本？)您是否对测试和QA流程有信心,升级将需要合理数量的开发资源并且不会导致重大回归？您是否考虑过最终还是用其他东西切换jQuery？等等.

当然这只是我的建议.其中有一些反复出现的主题,我希望它们很清楚.无论如何,我希望有人觉得这很有帮助!

Answer 3

这值得研究:https://github.com/jquery/jquery-migrate/#readme

此插件可用于检测和恢复已在jQuery中弃用并从1.9版开始删除的API或功能.有关插件生成的消息的详细信息,请参阅 警告页面.有关jQuery 1.9中所做更改的更多信息,请参阅升级指南和博客文章.