软件开发的未来

新冠病毒这个全球性的流行病，推动了数字化的发展，转瞬之间几乎所有的东西（至少大部分）都数字化了，许多人开始预测软件开发的未来。

软件发展趋势的文章不计其数，其中大多数都老生常谈，讨论了一些类似的趋势，如：人工智能、大数据计算、低代码开发、物联网、CI/CD、跨平台开发、混合现实（MR），当然还有云计算。

我将跳过大部分话题，另辟蹊径，讨论一下与敏捷开发相关的商业趋势。为了确保大家对概念的理解一致，首先，我要说明敏捷开发不是一种趋势。

再说一遍：

敏捷不是趋势，而是标准

敏捷开发是软件开发的过去、现在和未来。在 90 年代，我们经历了软件开发危机，那时从需求产生到正式生产的时间间隔是 3 年。2001 年在美国犹他州召开的雪鸟会议，也是关于敏捷开发的著名会议。尽管当时敏捷二字未被提及，但这个会议开启了许多快速交付问题的序幕。

到 2021 年，敏捷已经不再是趋势，软件开发的未来与敏捷开发不可分割。不过，对于企业来说，这是一个缓慢的过程。我经常与企业开发负责人接触，了解到目前暂没有一个企业计划采用或正在采用敏捷实践。

技术的发展规律显示，新的技术通常从初创公司萌芽，一旦发展成熟，价值凸显，就会慢慢被企业接受。尽管目前 95% 的初创企业报告（敏捷开发现状报告）使用敏捷实践，但企业的敏捷开发依然是缓步前行。细想也不难理解，成熟的大型软件企业要实现敏捷开发，必须经历一个比初创企业复杂十倍的过程。

CI/CD 是敏捷的一部分。当我咨询一些顶级企业客户时，了解到持续集成和持续交付都是所有公司研发战略的核心，无一例外。我知道关于趋势分析的文章中，提到 CI/CD 不少。但我并不认同这种观点，CI/CD 已经存在了一段时间了，也是讨论的热点。

不幸的是，在过去的 20 年里，超过半数的企业没能成功实现持续集成和持续交付，主要原因在于未能实现数字化转型（DX）。虽然新技术使用并不简单，但“敏捷之船”早已开航。

今天，是一个 “成者为王败者为寇”的时代，每个人都想要成王而不甘为寇。

在敏捷软件开发的 12 条原则中，前 3 条原则如下：

1. 通过尽早和持续交付提升客户满意度，这是真正的竞争优势。反过来说，如果不能提前持续交付，竞争对手将有机可乘。
2. 以灵活的方式构建开发周期，以方便后期调整。
3. 频繁交付意味着具有性能强大，并可以不断提升。因为发行版本中没有出现的功能，也是未能开发的功能。

敏捷开发的前期趋势，也引导我总结出即将讨论的这四个趋势，这是企业和机构需要了解的未来软件开发趋势。以下四个软件开发趋势，或者说预测，也是企业为了采用和维护敏捷开发，需要进行投资的方向。

这些趋势密不可分，相辅相成，帮助实现快速、自动化、高质量和灵活的软件开发。

敏捷的前提：

• CI/CD 自动化
• 自动化测试覆盖率
• 快速开发周期
• 高频迭代

能够进行上述实践的企业通常获益不浅，他们的产品因此可以加速上市，竞争力大幅增强，相应的客户满意度也得到提升。高频迭代的能力也可以转化为更高质量的产品，后期调整也更为灵活。
敏捷对企业的优势：

• 上市更迅速
• 更新发布（质量提升）更快
• 迭代频率更高
• 跨公司合作更顺利

我们不会讨论所有涉及企业敏捷开发的趋势，但是有四个趋势至关重要。我相信这对企业未来规划也有一定的意义，因此建议企业开发人员应该多加关注。

我将要介绍的内容可以分为两大趋势，实际上，这两大趋势在几年前就已经开始了。

左移趋势

左移趋势是指尽可能早地在开发过程中运行开发进程（例如软件安全性），因此无需牺牲开发执行时间。

开发人员在将代码提交到存储库之前运行测试，以便及时了解运行准确度，因此避免持续集成构建失败。或者在每次提交时运行代码分析测试，而无需拖到周末才进行测试。周末测试，意味着失败后，开发人员重新调整代码时距离编写已经过去一周。而及时测试，保证了高效修改。

云迁移趋势

另一个大趋势是云迁移，即将工作转移到云平台的过程。许多企业称之为“云化”，2010 年被认为是“云发展十年”，预测 83% 的企业工作负载将转移至云中。尽管新冠病毒对云的发展有着积极的影响，但云迁移仍然没有达到顶峰，不过这个发展趋势势不可挡。

不容分说，云迁移是一个主要趋势。尽管云迁移出现已久，但今年它终将达到顶峰。云服务提供商（AWS、微软和谷歌）也将随之达到巅峰状态（为测试云服务的公司提供免费预算）。组织（包括政府机构）不仅会积极讨论云相关的话题，采取响应行动，并理解云迁移需要什么。美国国防部与微软 Azure 达成的价值 10 亿美元的协议，就是一个很好的例子。很快，当他们打电话给我们询问关于 Incredibuild Cloud 的问题时，他们中的大多数人都会有一个清晰的云发展战略，了解云迁移路径，对发布自动化和在家办公的问题也一清二楚。

以下三个问题是阻碍企业和机构敏捷开发的主要障碍，要实现真正的敏捷开发，必须解决这些问题。

企业在进行敏捷开发时面临的挑战：

• 代码膨胀
• 测试中的技术债务
• 测试有限-覆盖自动化

从夜间 -> 每天 -> 每次提交

1.问题：测试覆盖率，技术债务

近年来的代码膨胀，究其原因，是背后大量开源项目的使用（另一个趋势），以及商业库和大量定制代码编写共同推动的。

代码膨胀导致编译时间变慢，自动化测试覆盖的代码范围也相应扩大。无论是功能测试、安全测试、压力测试还是其他测试，测试量都大幅上升。大量代码在极端时间内膨胀，对构建时间、测试覆盖率都是不小的负担。

测试覆盖范围引发的技术债务问题，对开发和发布过程产生了许多消极影响。

1.趋势：人工智能帮助更好更快测试

为了弥补这一技术差距，公司开始尝试各种各样的测试自动化解决方案。但我不想谈论纯粹的人工智能技术，尽管这是一个有趣的趋势，涉及大量资金投入（参见 Gartner 对 2021 年人工智能投资的预测）。相反，我想讨论基于人工智能的测试。

以人工智能技术为基础的测试，是解决测试覆盖技术债务问题一个有效方案。这个技术可以在较短时间内以合理的投资解决巨额债务。这里有一个有趣的数据：至少三分之一的测试专业人员计划明年使用机器学习让自动化测试更加智能。

基于人工智能的测试生成覆盖面广泛，从测试建议到开发人员、更快的测试生成、无代码测试生成，直到全自动的测试生成。

Diffblue 是一家有趣的公司，也是提供人工智能基础架构的先驱，可以自主编写大量的测试用例。更多的公司和解决方案正在出现（如：Testim.io，InteliTest 以及 PoniCode），相信我们后续会看到更多的优质产品，因为这类需求非常高。

由于 C++ 语言的特性，解释 C++ 代码（而不是像 C# 这种中间语言）更为复杂。因此要等到主流技术足够成熟，也能为 C++ 代码提供解决方案，还需要一定时间。

2.问题：完整的测试执行可能需要几个小时

一旦我们实现高质量测试覆盖自动化的目标，另一个问题又出现了。在测试企业级软件时，运行所有测试所需的时间可能极其漫长。一旦测试自动化启动并开始运行，所需的测试时间就会变得无穷无尽（如果我们使用膨胀，这里就是测试膨胀）。每次更新或更改都需要一个测试套件，这个过程又可能耗费好几个小时。

一方面，我们希望尽可能频繁测试，最好是每次提交前都能进行测试。另一方面，每次测试所需的时间或资源也是重大的负担。即使我们是在每次提交前运行完整的测试，好几个小时的测试时间也与真正的敏捷开发相悖，因为敏捷的目标是在 5 分钟内做出响应。在编译、代码分析等其他耗时进程中也会遇到类似的问题。

接下来的两个趋势正是针对这一问题，旨在以最小的代价让这些耗时的过程左移。

2.趋势：测试规避技术可以减少不必要的测试

在设法解决了测试覆盖率的问题后，测试的数量也让人堪忧。对于专注性能和自动化的企业级软件来说，更是如此。不仅仅是在测试的数量，企业必须承诺的测试种类更是层出不穷。例如下面列举的测试：

• 单元测试
• API
• 集成测试
• 回归测试
• 端到端测试
• 可用性测试
• 模糊测试
• DevSecOps 测试

作为企业，有时必须在不影响质量的前提下尽量减少测试的数量。每次更新或更改都需要一个测试套件，可能需要几个小时，难道真的要回到夜间构建的方式吗？还是回到衰退期？

这是一个恶性循环。

解决方法，是尽量是规避。开发人员一直在问自己，是否必须对每个更改运行测试？

答案是否定的，除非他们知道要运行哪些测试。

规避执行就是避免运行不需要的任务。不要运行所有的测试，只运行真正需要的特定测试。虽然我说的是规避测试，但规避编译也是这类技术趋势的一部分。当然，这类技术还是需要一定时间去适应。可能因为 Incredibuild 的原因，我的个人直觉还是想要尽可能多地进行测试。因为 Incredibuild 可以极大减少测试和构建时间，让我们随时随地尽可能多地运行测试（并经常运行构建）！但我必须承认，有一些新的方法正在得到重视，其中之一就是规避测试技术。

像 Sealights 和 Launchable 这样的公司可以帮助规避测试，这些公司在测试自动化工具中提供机器学习来识别重要的测试。了解要运行哪些测试来达到期望的置信水平，正是 Sealights 和 Launchable 等公司的功能。

下面是一个来自领先汽车制造商的成功案例图表，显示了使用 Launchable 运行正确的 20% 测试与运行随机选择的 75% 测试具有相同的置信水平。这个数据太令人惊讶。

投资回报率无疑大大提升，上市速度也大幅提升：

不过，Kohsuke 的解决方案的适用性还比较有限。另外，运行 25% 的测试用例依然需要好几个小时，企业需要一定的运行速度进行测试流程，且不影响速度、质量和执行频率。这也正是 Incredibuild 大展身手的时候，Incredibuild 的加速构建技术可以帮助减少测试时间。

3.问题：构建、执行缓慢

如前所述，冗长的构建进程是敏捷开发的主要障碍，不论这些是开发人员或构建服务器执行的漫长的C++ 编译，还是其他耗时的开发任务。

牺牲构建频率，在提交前未能运行构建，或者在每次提交前跳过了某个环节，最后在进程后期发现错误，导致需要调查构建中断的原因。这个过程冗长且乏味，也将耽误发布，更是无法预测具体的发布时间。

我们必须确保测试、编译和其他计算密集型进程不会将我们的企业拖回单向的瀑布式开发。

在当今高性能计算机、集群和分布式计算的世界中，因计算能力有限导致进程冗长耗时已经是一个过去式问题了。

3.趋势：高性能计算

新的 AMD 处理器厂商以价格合理的多核计算机打乱了市场（如 64 核桌面处理器为许多高需求的工作负载提供了卓越的性能），分布式计算使公司能够轻松地使用成百上千的内核，进行编译、测试和其他计算密集型应用程序进程。

我相信大型的基础架构解决方案，这是无法用硬件解决的问题。使用分布式计算，可利用的基础架构不受限。

以 Minitab 为例：它们的测试覆盖率很高，它们生产的软件质量也相当有保证。但这种质量是有代价的，11 小时的测试周期。就算将构建服务器从 32 核升级到 64 核，以减少测试时间，这也丝毫满足不了他们对高敏捷度和高性能的要求（显然，11 分钟更具吸引力）。通过分布式计算，Minitab 可以无缝扩展构建服务器，根据需要，利用成百上千个内核来分发测试。这些内核资源可以是本地网络中主机的闲置内核，也可以是按需调用云资源，甚至是便宜的 Spot 实例，客户可以根据自身的动态需求自动进行上下扩展。

作为 Incredibuild 技术首席官，我在过去 10 年见证了各个企业孜孜不倦提升计算能力的过程。现在，他们已经拥有了数千个网络中的闲置内核，通过这些内核，每台主机可以扩展到拥有1000个内核的超级计算机，并利用这些资源帮助构建开发。有了分布式计算，一切皆有可能！

虽然测试是高度集中的，但它并不是企业 CI/CD 中唯一导致构建周期拉长的进程类型。还有其他一些进程受计算能力的约束，比如编译、代码分析、资产创建、代码签名、打包等等。

另一个我认为已经足够成熟的趋势是云托管 CI/CD 解决方案。

4.趋势：云托管 CI/CD 将自动执行发布管道

最后一个趋势已经足够成熟，也适合企业发展，那就是云托管 CI/CD 解决方案。

好吧，云迁移是一种趋势，CI/CD 是一种有争议的趋势（在我看来，这是一种“过去”的趋势），那么为什么不联手在云中运行 CI/CD 呢？毕竟，这样操作优势不少。

对企业来说，云中的 CI/CD 优势在于灵活性、可扩展性、自助服务、维护、安全性以及业务原因，例如公司可以将预算转移到运营成本而不是资本成本上，这意味着，每年只需购买预计需要的服务，而不是购买昂贵的硬件，并预估能使用几年。

现在，让我们开始讨论实现完整 CI/CD 所需的工具。

亚马逊 AWS、微软 Azure 和谷歌云平台等主要云供应商，以及 Jfrog、CircleCI 等其他供应商，正在竞争 CI/CD 提供端到端托管云方案和构建管道的主导地位，一场恶斗正在开启。

这些工具在创业生态系统中历经磨炼，并逐渐成熟。CI/CD 托管服务最初受到初创公司的青睐，主要用于需要频繁发布的领域，如 web 应用程序、云服务和移动应用程序。

如今，在这些服务成熟之后，我们看到大型企业也在缓慢开启这些实践。我们的一些大型企业客户已经将其本地 CI/CD 转换为完全托管的云解决方案。尽管他们对将企业的源代码放入公共云，放在企业网络之外，仍有顾虑。回顾几年前，这些公司也曾不愿意将其业务数据和客户详细信息迁移上云，更不想与第三方供应商共享源代码。但今天，大多数企业公司都在使用 Salesforce 和 SAP 等服务，将其全部业务数据保存在云中。

此外，云相关技术不仅围绕托管 CI/CD 服务发展，还渗透进入整个开发生态系统。云中的存储库、面向开发人员的远程构建、虚拟桌面和用于测试的 SaaS 解决方案等等只是冰山一角，这些都是软件行业正在发展的方向。

其他云迁移解决方案：

• 云存储库（GitHub、GitLab、Perforce Cloud）
• 面向开发人员的云构建（GitHub 代码空间）
• 虚拟云桌面
• SaaS 测试-应用程序
• 在家办公带宽优化，Teradici
• 等等…

在企业开发超速前，请先评估资源和优先事项

每个企业中的每一位数字、创新、技术决策者都必须了解他所服务的公司的成熟度和发展阶段。

在感受到新冠病毒的影响后，每个企业都必须制定迁移到云、持续自动化、协作和支持在家办公的策略。最好的例子是游戏工作室：因为自动化方面投入了大量资金，世界领先的游戏工作室不仅成功地在新冠流行的关键阶段发布了新游戏、进行了更新和修复，甚至能继续开发新业务。

每个组织都必须了解自身的局限和策略，了解如何向自动化和敏捷开发迈进。否则，这些从 2000 年起就在领先阵营的老牌企业，很有可能会被快速发展的创业公司取代。

大企业，并不意味着更新缓慢、技术落后，反而代表了更多的资源和带宽，用于加速创新。找出短板，并迅速修补，才是企业生存的硬道理。

点击了解 Incredibuild 加速 C/C++ 构建编译的解决方案，并获取试用 License！