不断变化的框架/API——我们如何跟上?

预测和投资变革。

许多企业似乎认为改变是件坏事。它使原本的工作过程复杂化。但作为开发人员,我们的看法往往不同。

更改,特别是新版本,可以带来许多好处,如安全更新、性能增强和功能。变化往往是不可避免的。那么,为什么不把它视为现实情况而不是惊喜呢?

你可以做一些事情,比如让你的数据以非特定于供应商的格式备份,以防一些新的尖牙技术不能奏效,你需要跳船。

另外,如果您有足够的资源,您可以让某些东西的旧版本和新版本同时运行。理想情况下,在有人评估并签署之前,您不会希望您的生产系统运行最新和最好的软件。像单元测试和生产系统的测试/开发克隆之类的东西可以在这个过程中提供帮助。

改变应该被接受,而不是害怕。开发人员、利益相关者和业务人员都应该了解新技术和框架。随时准备应对变化。在苏俄,API跟上你!

哦,可能的答案……

我的想法,虽然不是独一无二的(可以肯定),但基本上是这样的。

1. 在源代码管理中分支代码——您使用的是源代码管理,对吗?
2. 在分支上,更新框架(或者您拥有什么)
3. 解决单元测试中的问题。利用新的框架API,删除已贬值的引用等
4. 彻底测试。
5. [可选]推回后备箱(这和4可能会翻转)
6. 发布到生产环境-恭喜,您现在进入了新的框架。

这并不容易,但我相信最简单的答案可能是最好的答案。你必须向前走…

我看到的唯一两个“解决方案”是您的建议:保留或升级到新框架。我认为,通常情况下,当您的API收到重大更新,并且您的软件很重要时,最好评估升级的好处,如果这些好处超过了升级所需的时间,那么最好的做法就是升级。

选择一个保守的,有风险的,或者介于适合你的业务的方法之间的方法,并坚持到底。

例如,如果你的公司是关于创新的,你需要能够使用最新版本的框架——或者至少自由地调查它们。你需要雇佣对这样一个环境感兴趣和舒适的人——一些开发人员对此非常兴奋,其他人则不那么兴奋。加入一些结构来保证升级的安全(分支和静态结构)。客户应该理解与这样一家尖端公司合作所带来的好处——如果你不与他们沟通,这可能不是他们看重的东西,而且当事情因为系统更新而中断时,他们会(正确地)感到不安。

或者选择一个保守的方法。选择一个坚实的,磨损严重的技术,不要计划更新它,除了小版本。用你的话说,目标是一个特定的版本。雇佣欣赏这种环境的人。

或者在路中间再选点什么。

这些方法中的每一种都适用于不同的时间——我在不同的项目中都处于两个极端。