去年春天，我写了一篇博客文章，介绍了我们正在幕后进行的逐步简化 curl 源代码的工作。
这是后续报告：汇报一下我们自那以后所做的事情以及接下来的计划。
2025 年 5 月，我刚刚成功地将 curl 中最差的函数复杂度降低到 100，所有 curl 生产源代码（179,000 行代码）的平均得分是 20.8。我们还有 15 个函数的得分超过 70。
历经近十个月，我们将 curl 中最复杂的函数从 100 行精简至 59 行。这意味着我们简化了大量的函数。我们通过将它们拆分成更小的部分并重构逻辑来实现这一目标。这些工作经过人工审核、大量测试用例验证以及分析器和模糊测试器的检查。
目前 171,000 行代码的平均复杂度为 15.9。
复杂
在这种情况下，复杂度评分仅仅是pmccabe工具提供的原始冷冰冰的指标。我决定将其视为绝对真理，即使人们有时可能会对其结果提出质疑和异议。但这样做更简单，因为工具本身的表现也相当不错，所以这不成问题。
如何简化
几乎所有情况下，复杂函数的主要问题在于它们在一个函数中执行了太多功能——实际上，这些功能完全可以（或者应该）拆分成几个更小的子函数。几乎在所有情况下，将一个函数拆分成两个、三个或更多个作用域更小、更具体的子函数后，代码会变得更易于理解，而且每个子函数也更容易调试和改进。
发展
我不知道我们可以把代码简化到什么程度，也不知道 curl 代码库的理想平均复杂度是多少。过度简化会适得其反，进一步缩小函数只会让代码流程更难理解，也更难将正确的上下文信息吸收进去。
图表
为了展示我们的简化历程，我决定绘制一些图表，时间轴从 2022 年 1 月 1 日开始，到今天结束。这四年多一点的时间，代表了近 10,000 次 Git 提交。
首先，我们来看一下过去四年 curl 生产代码中得分最低的函数的复杂度，并与 P90 和 P99 进行比较。
找出最差的函数可能无法说明代码的整体问题，因此还需要检查平均复杂度的变化情况。计算方法如下：
- 所有函数都通过 pmccabe 获得复杂度评分。
- 每个函数都有若干行。
对于所有函数，将其函数得分乘以函数长度，得到总复杂度得分，最后将该总复杂度得分除以所有函数使用的总代码行数。同样，计算中位数得分。
2022 年初，平均值约为 46，从那以后就一直在下降，在我们合并专门的改进工作时，出现了几次急剧下降。
为了完善平均值和中位数线，从而更好地了解该州的情况，一种方法是检查代码中仍然很复杂的部分有多少。
这表明，2022 年代码中最复杂的四分之一已被简化。当时，25% 的代码得分超过 60 分，而现在所有代码的得分都低于 60 分。
这也表明，在2025年，我们成功清理了所有暗函数，这意味着复杂度超过100的函数将不复存在。至少按照计划，它们将永远不会再出现。
这重要吗？
我们其实并不清楚。我们认为降低代码复杂度通常有利于安全性和代码可读性，但现在要衡量这项工作的具体积极成果（除了精美的图表之外）可能还为时尚早。此外，评估代码的方法远不止复杂度评分。例如，拥有合理的内部和外部 API，并确保它们有完整且正确的文档等等。由于所有这些因素相互交互且不断变化，因此很难将复杂度这样的单一因素单独分离出来，并断言仅仅改变复杂度就能产生影响。
此外：也许仅仅是重构本身以及在重构过程中对函数的关注，就可能解决问题或引入新问题，而这实际上并不是由于复杂性的变化，而仅仅是因为有人关注了代码并立即对其进行了修改。
或许我们需要再过几年才能衡量出任何变化？
原文： https://daniel.haxx.se/blog/2026/02/24/decomplexification-continued/