代码膨胀会破坏开发操作吗，它将如何影响编译时间？

在这里插入图片描述
Incredibuild 正潜心研究公司以及客户的未来发展趋势。

过去的一年举步维艰，但聪明的企业总是能够抓住机遇，将大部分业务自动化，保持敏捷度和竞争力，最佳的案例就是游戏工作室。这一年来，用户对新游戏或新版本的期待达到前所未有的高度，希望发布速度越快越好。事实证明，他们没有辜负这个期待。

比如 Milestone 在新冠肺炎封锁期间发布 MotoGP ™ 20。

在 2021 年的时候，我无意中看到这篇文章使用了 Sourcegraph 和 Dimensional Research 的报告。报告显示 33% 的开发人员（在 500 多名受调查者中）比 2010 年多管理了 100 倍的代码；18% 的开发人员管理的代码比 2010 年增加了 500 倍！

在这里插入图片描述
图片来源: Sourcegraph

这意味着每年要多出 2 到 15 倍的代码行。

诚然，这并不意味着我们写出来的代码比十年前多出 100 倍。但改变已然发生，比如大规模的开源应用、各种各样的设备、环境等等。

在这里插入图片描述
图片来源: Sourcegraph

但对我来说，这是一个改变游戏规则的时刻，任何软件开发领域的人在为未来做准备时都需要考虑这一点。

代码膨胀的趋势愈发急剧。如果这种趋势是合理的，两年内将翻一倍甚至两倍，这也将给资源和基础架构带来负担。

软件开发第一定律

研究人员 Gerard J. Holzmann 在谈到这种代码膨胀趋势时，说道：“不论是否有合理的需求，软件会随着时间的推移而增长，我们可以称之为软件开发的第一定律。”既然 Holzmann 把这种代码膨胀的趋势称为软件开发的第一定律，也说明了这一趋势的重要性。Holzmann 深入探索了这个理论，为了证明这种不合理的代码膨胀，他研究了 Unix® 和基于 Unix 的系统中称为 true 的命令。随着时间的推移，这个命令从 0 增长到 22896，这也证明了他的观点。此外，也说明了即便是最琐碎的代码也会膨胀。试想，当涉及到复杂产品时，情况将多让人悲观。

影响迭代频率

那些不愿意使用最新技术，对代码膨胀一无所知的公司，将被埋没在混乱之中，永无出头之日。想象一下，系统变成了无难以维护的遗留系统，太多的东西无法处理。更可怕的是，还有错综复杂的依赖关系！当涉及到膨胀的代码或遗留系统时，依赖关系最让人头疼。根据这份报告，57% 的被调查者指出有过因依赖关系理解缺失导致代码破坏的经历。

在这种情况下，快速编译攸关生死，从长远来看，我推测会有更多的硬件帮助解决编译时间的问题。所有这些膨胀的代码行都必须设法进行编译，并且加速高频地进行。另外，速度是关键，十多年前就已如此；本报告中的绝大多数受访者（92%）表示，在过去十年中，加速发布代码的压力有所增加。因此，不仅仅是代码膨胀导致了加速编译需求的提升，高速的迭代周期和发布速度更是对编译速度提出了更高的要求。

在这里插入图片描述
图片来源: Sourcegraph

决定产品质量

更多的代码意味着更大的测试覆盖范围，包括单元、API、集成、功能测试、安全漏洞检查、代码质量分析或中间的操作等等。

当涉及到自动化测试覆盖率时，当今大多数软件公司都深陷“技术债务状态”。在全自动化 CI/CD 发展势不可挡的情况下，如果想要保持频繁和高质量的发布，广泛的测试覆盖必不可少。

在这个代码膨胀的时代，有几种方法可以支持持续集成，并处理技术债务的问题。我现在正在研究的一个非常有趣的途径是测试生成器。了解到 Diffblue 开发的一个新的人工智能工具，可以自动编写 Java 的单元测试（他们还提供了这个产品的免费社区版，是用 IntelliJ 创建的）。

而随着人工智能工具定期自动生成数以万计的测试单元，测试膨胀也即将来临，测试量将达到现在的 100 多倍。

现有的工具无法处理代码膨胀（当然，除了我们）

报告指出，85% 的受访者同意“现有的工具并不是为大规模处理大型代码库而设计的。”这也是我为 Incredibuild 自豪的原因之一，即我们顺势而为，以领先的技术高效应对代码膨胀。Incredibuild 让代码构建速度大幅提升。在自动化测试覆盖率大幅增长的趋势下，Incredibuild 也能完美地满足客户需求，以最快的速度实现最好的产品。

可以适当做些代码清理

除了用正确的技术武装自己（这正是我们在这里的目的），从技术来说，最好检查一下可否删除过时的代码。诚然，这需要相当多的努力和毅力，且不是每个人都能做到。有些情况不适合代码清理，或者根本不值得这样做。但在合适的情况下，代码清理还是值得一试。我知道很多开发人员都避免更新代码，因为害怕破坏代码（正如报告所示）。这种想法是可以理解的，但代码膨胀更让人害怕。