持续集成之道
现代软件开发中有一个不言而喻的真理：健壮的持续集成（CI）系统是必不可少的。但许多项目却饱受脆弱CI系统之苦，这些系统让开发人员感到沮丧，并严重阻碍了开发速度。为什么会这样？你能做些什么来避免常见的CI陷阱？
持续集成需要有目的
CI本应提供额外的保证，确保项目代码的正确性。然而，开发人员为验证预期功能而编写的测试在最初编写时效用最低。这或许有违直觉，因为开发人员最初编写代码时对代码最熟悉。他们从多个角度思考过，考虑了许多可能的边缘情况，并实现了相当不错的功能！
不幸的是，编写代码是编程中最简单的部分。真正的挑战是构建他人能够阅读的代码，使你的项目能够长期繁荣发展。软件熵随时间增加。开发人员——尤其是不熟悉大型长期代码库的开发人员——无法预料他们的代码将如何被集成、重构和重新调整用途，以满足最初未考虑的需求。
当这些重构和扩展发生时，测试是能够自信进行更改的唯一方式。那么，为什么开发人员最终会缺乏高质量测试的系统呢？
琐碎的测试
在编写测试时，尤其是为了达到高代码覆盖率指标时，最常见的抱怨是某些测试过于琐碎，没有触及代码库中有趣或容易出错的部分。在考虑当前代码时，这些抱怨是合理的，但现在设想软件可能被重新调整用途，不再是最初的意图。曾经琐碎的部分现在可能变得微妙。未能测试琐碎情况可能导致你的工作陷入由不可观察行为所隐藏的陷阱迷宫。
请记住以下三点：
- 从长远来看，没有测试是琐碎的。
- 测试是预期行为的文档。
- 未经测试的代码容易发生意外行为变化。
不可靠的CI
不可靠的CI对开发人员来说是毒药。对于内部项目，它会降低生产力，让人们讨厌在上面工作。对于开源项目，它驱赶贡献者的速度比他们到来的速度还快。
找出导致测试不可靠的原因并修复它。不可靠的CI通常表现为不稳定的测试，现有工具可以将测试标记为不稳定，直到你找到根本原因。这将允许你在不拖累团队的情况下立即改进CI。
缓慢的CI
你可能会发现CI周期时间过长。这是有问题的，因为高质量的开发过程要求所有CI作业都通过。如果周期时间太长且复杂，以至于在本地运行不切实际，那么开发人员将创建变通方法。这些变通方法可能采取多种形式，但最常见的是PR规模膨胀，因为没有人愿意提交一个只有两行代码的PR，等待一个小时才能合并，然后重新调整他们300行代码的PR。更糟糕的是，他们可以在一个PR中做一些不相关的更改。这给代码审查者带来了问题，并降低了项目质量。
开发人员这样做并没有错，是CI让他们失望了。在构建CI系统时，重要的是要记住一个延迟预算，即“CI不应慢于时间t，其中t是事先选择的。”如果CI变得比这更慢，那么即使它侵占了新功能的开发，也要努力改进它。
覆盖率很难
负责任测试的一部分是了解你的测试正在执行哪些代码行——一个简单而漂亮的数字告诉你一切。那么为什么覆盖率如此常被忽略？
首先，技术挑战。现代软件针对许多不同的目标运行。为了有用，CI系统应针对多个目标运行，这些目标将数据提交到可以合并覆盖率的托管系统。（这类工具失败带来的挫败感，以及尽管所有软件都是热垃圾，如何保持开发速度是另一个讨论话题。）如果没有这个，服务软件开发人员通常不会注意到遗漏的覆盖率，因为它消失在“预期”遗漏行的噪音中。
现在让我们谈谈社会挑战。软件通常以难以测试小功能块的方式编写。这个问题催生了测试驱动开发（TDD）趋势，即先编写测试，以帮助开发人员以可测试的方式构建代码。这通常在可读性和可测试性方面是净收益，但需要纪律和不同的开发方法，这对许多人来说并不自然。
使更多代码库可测试的 perceived drudgery 导致抱怨覆盖率是一个不完美的指标。毕竟，并非所有代码分支都是平等的，根据你的语言，某些代码路径永远不应被执行。这些并不是将覆盖率视为有价值指标的充分理由，但在特定情况下，可能存在令人信服的理由不花费精力用测试覆盖某些内容。然而，请注意，未能用测试覆盖某段代码，其行为就不再是未来开发人员在重构期间将遵守的契约的一部分。
我们该怎么做？
那么，面对所有这些障碍，我们如何达到CI的涅槃境界？逐步进行。现有项目是宝贵的资产，我们希望保留我们所拥有的，同时提高未来改进的能力。（重写几乎总是一个坏主意。）这需要一个渐进的方法，虽然针对特定项目进行了定制，但有一个广泛的配方：
- 使CI可靠
- 加速CI
- 提高测试质量
- 提高覆盖率
我们都应该花时间投资于我们项目的 longevity。这种基础性努力会迅速带来回报，并确保你的软件项目能够达到世界级水平。
如果你喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News