28

我们正在进行的一些项目在 jQuery 1.4.2 或更早版本中有着深厚的渊源，介于缺乏最新版本的性能优势（或语法糖）、使用现已弃用的方法的耻辱以及部署一个 3 年以上的积极维护库的旧版本，升级现在迫在眉睫。

我们可以采用/重新访问社区中哪些流行的做法以确保顺利推出（即关注晦涩的兼容性问题，拾取全局回归，重构一些旧代码......）？它们如何最好地集成到 SDLC 中以供将来升级？对于 jQuery 之类的库来说，合理的升级计划是什么（我预计每次发布都不会有显着的收益或合理的成本，但每 6-12 个月一次可能是合理的）？

4

6 回答 6

13

要真正回答您的三个问题，以下是我做过或至少推荐的一些事情：

顺利升级推出的最佳实践

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

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

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

合理的升级时间表

这本质上是一个 CBA/风险管理问题。你必须权衡一些事情：

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

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

于 2013-03-19T18:15:27.407 回答
12

你永远都会过时。更新到最新版本后，几个月后会出现更新的版本。

除非您愿意投入数小时/数天/数周的开发、测试和错误修复，否则可能会破坏面向用户的功能，否则您不应该仅仅为了使用声明事件处理程序的最新方式而进行更新。它不会伤害你。通常这是一个冒险的事情。这转化为开发团队成本。你已经知道了。重构，尤其是在项目没有明显风险的情况下，通常很难向管理者证明是合理的。你应该仔细检查你的想法，以确保在已经运行的代码中使用新的 jQuery 是否会产生任何影响。

现在，如果您正在现有站点中创建新页面，您可能会在这些区域中包含一个新版本。但是，这将产生一个后果：假设您和您的团队除了开发网站的新部分外，还必须维护使用旧部分的部分。每个人都需要了解他们编写代码所针对的特定版本的 jQuery。

所以，要结束，我会说这样的话。除非由于旧的 jQuery 版本而导致项目延迟或在技术上被阻止存在真正合理的风险，否则您将因为破坏已经工作的东西而陷入麻烦，并且需要额外的时间来完成所有事情和以前一样工作。

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

于 2013-03-11T03:31:18.890 回答
6

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

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

于 2013-03-11T03:16:26.770 回答
1

Twitter的家伙已经很好地解决了这个问题。

http://github.com/twitter/bower

它做它在锡上所说的 - 它是一个网络包管理器（包括保持 JS 文件，如 JQuery 最新）

于 2013-03-19T17:04:10.283 回答
0

为了在您的开发树中保持最新，我建议使用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）由于这些会定期更新错误修复版本，它们不会像特定版本那样被缓存发布

于 2013-03-19T04:07:48.050 回答
0

在这个时代，我们无法预测任何软件版本的稳定性。几年后软件和服务的版本发布之前的一年或两年。但是此时服务的版本正在快速且频繁地更新。

因此，如果您将任何服务与您的服务一起使用，则必须使用敏捷开发。通过这种开发方法，您可以轻松地对新需求进行更改，并根据您的需要更改所需的方法。

并且请不要使用折旧方法，因为它们不适合长期服务版本。并将使用其他服务的自己的服务功能库中使用的服务制作库，以便您可以根据新版本轻松更改它们。

例如：就像您有一个方法名称一样update_var();，它正在调用其他服务的另一个方法，例如$a = newlib::check_update();。然后通过创建库，您必须更改您的功能的主库和相关服务的核心库

于 2013-03-19T04:41:02.857 回答