代码复杂度的识别线索

以下是一些表明你的代码可能过于复杂的线索：

• 你必须添加“hack”来使功能保持正常工作
• 其他开发者不断询问你某部分代码的工作原理
• 其他开发者经常误用你的代码，导致bug产生
• 有经验的开发者阅读一行代码需要超过一瞬间的时间
• 你害怕修改这部分代码
• 管理层认真考虑为单个类或文件雇佣多名开发者
• 很难想出如何添加新功能
• 开发者经常争论在这部分代码中应该如何实现功能
• 人们经常对这部分代码做出完全无意义的更改，你只能在代码审查期间或更改提交后才能发现

读者补充的复杂度线索

Andrew Pennebaker的建议：

• 代码与其他代码协作不佳（API弱或没有API）
• 每个函数似乎都需要自定义输入类型
• 编译或解释速度慢
• 项目需要多种编程语言
• 很难将项目与其依赖项解耦或切换到替代库
• 开发者讨论从头重写整个项目

Jerome的观察：

• 方法参数列表随时间失控增长
• 你觉得需要注释控制块的结束（称为“if”膨胀）
• 编写良好的覆盖测试所需的代码比要测试的方法本身更多

Palo的经验：

• 系统很复杂时，很容易犯错误（结果是“你害怕修改这部分代码”）
• 为了添加新的业务规则，必须检查和/或修改几个不相关的地方

Vidhyut的观点：

• 复杂软件通常具有大量依赖关系
• 如果无法将一个类从一个项目复用到另一个项目，这表明你有一个紧密耦合的复杂系统

Mike W.的贡献：

• 整个代码库是一个“大泥球”

关于代码复杂度的本质思考

代码质量测量的局限性

Google代码健康组的经验表明，所有试图创建定量指标（圈复杂度、静态分析失败计数、确定内聚和耦合的算法）的尝试都失败了——它们将团队引向错误的方向，并没有解决真正阻碍开发者的重要问题。

代码“简单”的定义是：易于阅读、理解和正确修改。其中的“阅读”和“理解”本质上是主观的。只有人类才能告诉你某物是否易于阅读。

现代LLMs的局限性

现代大语言模型在判断代码质量方面表现一致不佳。它们擅长发现特定问题并以代码审查的形式提供具体指导，但完全缺乏经验丰富的软件工程师在创建真正简单软件系统方面的判断力。

开发者体验的基础

Google优秀的开发者体验关键在于专注于软件工程的基础：

• 代码库是否可维护？
• 你是否拥有高效构建可靠、高质量软件所需的基本工具？
• 是否有系统确保新软件工程师能够快速上手项目，并随时间提高技能？

技术领导者最常见的错误之一是未能专注于所有这些工程基础，而是坚持在破碎的基础上紧急解决眼前问题，没有任何真正解决这些基础的计划。

结论

代码质量本质上是主观的，如果你想理解它，你需要关于它的主观数据。这是唯一被证明有效的方法。