代码复杂度的线索
以下是一些表明你的代码可能过于复杂的线索：
- 你必须添加“hack”来让功能继续工作
- 其他开发者不断询问你某部分代码的工作原理
- 其他开发者经常误用你的代码，导致bug
- 有经验的开发者阅读一行代码需要超过一瞬间的时间
- 你害怕修改这部分代码
- 管理层认真考虑为一个类或文件雇佣多名开发者
- 很难想出如何添加新功能
- 开发者经常争论这部分代码应该如何实现
- 人们经常对这部分代码做出完全无意义的修改，你只能在代码审查时或在更改已提交后才发现
这些是我能立刻想到的。还有其他什么线索吗？
-Max
评论
Andrew Pennebaker 说：
- 代码与其他代码配合不佳（API弱或没有API）
- 每个函数似乎都需要自定义输入类型
- 编译或解释速度慢
- 项目需要多种编程语言
- 很难将项目与其依赖项解耦或切换到替代库
- 开发者讨论从头重写整个项目
Max Kanat-Alexander 回复： 是的，这些很好！虽然我不会说缓慢的解释/编译或需要多种语言一定是复杂度的指标。有些语言就是有慢的编译器，有些项目就是很大，有时你必须使用多个工具来完成工作。
-Max
John 说： “管理层认真考虑雇佣多名经理来管理处理单个类或文件的开发者”怎么样？
Max Kanat-Alexander 回复： 哈哈哈！
Jerome 说： 其他几个：
- 你的方法参数列表随时间失控增长
- 你觉得需要注释控制块的结束（我称之为’if’膨胀）
- 编写一个良好的覆盖测试需要的代码比你想要测试的方法更多
Max Kanat-Alexander 回复： 是的！这些相当好！虽然，就测试编写而言，我实际上发现测试比代码大是很常见的。我认为这可能更多是需求复杂度的问题，而不是代码复杂度的问题。
-Max
Simon 说： 依赖树看起来像这样？ http://thedailywtf.com/Articles/Enterprise-Dependency-The-Next-Generation.aspx
Max Kanat-Alexander 回复： 哈哈哈！！确实是WTF！！
-Max
Raghu 说： 在阅读了Simon上面的评论后，我去了那个网站并发现了这个。 http://thedailywtf.com/Articles/Serious-String-Validation.aspx ~raghu
Palo 说： 嗨Max，我真的很喜欢你的博客文章。去年我在为一个批处理系统工作，用于从大型数据集中计算统计信息。为了添加新的业务规则，我必须检查和/或修改几个不相关的地方，包括spring bean、属性文件和其他东西，所有这些都很琐碎，但很容易出错（例如，有一个DB2/Oracle小数/整数问题，没有人在第一次就做对）。所以我认为当一个系统很容易出错时，它就是复杂的（结果是“你害怕修改这部分代码”）
Max Kanat-Alexander 回复： 嘿Palo！感谢你的好话！是的，我同意，“太容易出错”是一个非常好的线索。
-Max
Srihari S 说： 如果你的代码有异味，它就是复杂的。参考WIKI：代码异味。
Steve Bush 说： 我昨天从头到尾阅读了《代码简洁性》！（电子书有“封面”吗？）。并且很享受！我想说大约50%我同意，剩下的50%我强烈同意！我想我可以挑剔几个点，（并期待在将来的某个时候这样做！），但总的来说，我大部分同意你的初始陈述，即无论它可能是什么，它都是一个开始！而且是一个非常可行的开始！
我不介意看到一个博客/课程/午餐系列，每个课程期间（或博客条目）提出一个规则或定律进行讨论！那将是一个有趣的对话！
我有两个与编码点无关的评论要添加：
我从书中得到的一个全新的事情是物理组织。每条定律、规则、事实、定义在出现时都被标识出来，然后当我到达结尾时，我得到了一个列出每一个的附录！这创造了对整本书的精彩回顾！我非常喜欢这一点，就像在最后5分钟内几乎在精神上重新阅读整本书一样！太棒了！
另一个无关但可能有趣的点是我阅读的方式：通过iPad iBooks应用程序。我阅读非常多，但几乎总是通过网页浏览器。我注意到我几乎在阅读时不断滚动；在iPad上，我的拇指让文本像自动提词器一样上升，以便我的眼睛始终保持大约相同的高度；在Mac上，我用两个手指放在触控板上做同样的事情阅读。但iBooks保持文本静止，我的眼睛从上到下移动。我不能说这是否优越，只是觉得不同，并提醒我们自从那些纸的东西，哦是的，书！以来已经走了很长的路！
一个幽默的愚蠢行为：我一次去了iBook的目录，它在屏幕上只显示到第2章。我花了整整五分钟试图让剩余的章节显示。页面不会翻动！我几乎放弃并决定这是一个错误，当我意识到，目录可以滚动!!!!!! 无论如何，你做得非常好，非常感谢！我很享受，我相信我的编程将来会从中受益！
Steve
————- “我们现在玩得很开心！”
Vidhyut 说： 复杂的软件大多有大的依赖性。所以如果你不能将一个类从一个项目重用到另一个项目，这是一个信号，表明你有紧密耦合和复杂的系统。
Mike W. 说： 这个怎么样：
- 你的整个代码库是一个大泥球。 http://www.laputan.org/mud/mud.html
Max Kanat-Alexander 回复： 信不信由你，我曾经认识一个人，他使用那个特定的术语来自豪地、有意地描述他的系统设计，好像它是一个应该被保留的合法设计选择。
代码质量的主观性
我几乎每周都参加Google代码健康小组的周会，从2011年直到我们在2015年左右停止定期周会。这是一个非常棒的会议，有一个核心小组几乎总是参加，加上每周一些一次性的与会者，他们希望在他们的领域获得有关代码质量、测试或重构问题的帮助。
大多数情况下，会议作为一个支持小组，为那些关心代码质量并希望在他们领域做些什么的人服务。他们会出现，抱怨他们关心但难以让别人关心。我们会支持他们，说我们真的关心，他们应该继续前进，然后他们会回到他们的领域做伟大的事情。实际上令人惊讶的是，那个会议的许多与会者后来成为了Google一些最资深的技术负责人。（关于长期职业成功的一个好说明：如果你专注于做正确的事情，尽管有反对或困难，从长远来看，这几乎总是对你的职业正确的事情。我们肯定在代码健康小组中一次又一次地看到这种情况发生。）
然而，几乎每周，都会有人出现在会议上问我们同样的问题：“我如何客观地测量代码复杂度？”周复一周，我们会给他们同样的答案：“没有办法做到这一点，请不要。”
这个小组的负责人代表了代码质量和重构领域世界上一些最有经验的工程师，我们随着时间的推移都得出了相同的结论：代码复杂度测量不起作用。所有制作定量指标（圈复杂度、计算静态分析失败、确定内聚和耦合的算法）的尝试都失败了——它们导致团队走错路，并没有解决真正阻碍开发者的重要问题。
最终，我意识到为什么这些指标不起作用，而且永远不会起作用。这是因为代码“简单”的定义是：易于阅读、理解和正确修改。那里的“阅读”和“理解”本质上是主观的。只有人类能告诉你某物是否易于阅读。
有些人希望现代LLM能在这里提供帮助。当我看到它时我愿意相信，但现在这实际上是所有模型一直糟糕的领域：告诉你是否产生了高质量的输出。它们在发现特定问题并以代码审查的形式提供具体指导方面很好。但它们完全缺乏经验丰富的软件工程师在制作实际上简单的软件系统方面所具有的判断力。无论你告诉它们多少“要简单”或“编写好代码”，它们根本做不到。
所以这仍然是真的：代码质量本质上是主观的，如果你想理解它，你需要关于它的主观数据。这是我见过的唯一有效的东西。
开发者体验的基础
为什么Google有如此伟大的开发者体验？它只是在这方面花了比任何人都多的钱吗？
嗯是的，如果你加起来曾经花在Google基础设施上的所有人力成本，Google可能在开发者体验上花的钱比任何人都多。但这实际上不是Google在这里成功的核心原因，因为Google开发者体验的早期没有涉及很多工程师。它实际上涉及相对较少的不错工程师，他们相当缓慢地随着时间的推移构建工具。Google一些最受喜爱的工具最初是由三、四个人构建的，总共。
关键是这些工程师被允许专注于开发者基础设施的基础，无论需要多长时间才能做好。每个人都在构建面向开发者体验的长期全局最大值，而不是短期即时需求。非常好的工程师被给予自由问诸如“一个完美的构建工具会是什么样子”的问题，然后尝试构建它。源代码控制、代码审查、编程语言基础设施、CI、IDE、公共库和开发者体验的许多其他部分也是如此。当然，有时我们在过程中构建了糟糕的东西，但公司足够关心做好它，以至于我们（通常）回去修复它，最终。
Google开发者体验和速度的关键是这种对软件工程基础的关注。它也不仅仅在开发者工具团队中，而是贯穿整个公司——Google的工程师比我在任何其他地方看到的都更关心代码质量、测试等。
行业中其他地方的技术领导者最常犯的一个错误是未能关注所有这些工程基础。代码库可维护吗？你有需要的基本工具来高效、有效地构建可靠、高质量的软件吗？是否有系统确保新软件工程师可以快速上手项目，并随着时间的推移提高他们的技能？等等。
相反，我经常看到领导者坚持在破碎的基础上紧急解决即时问题，没有任何计划真正在未来解决那些基础。这有点像是一个酒店建造者，看到所有其他酒店都有伟大的顶层套房，然后坚持团队在建筑有裂缝的基础和漏水的管道时建造一个美丽的顶层套房。修复那个基础可能很困难，但如果你不这样做，你肯定会后悔。
基础有时感觉抽象或不重要，因为它们不是你被要求交付的即时产品。但让我告诉你，如果你想能够交付任何东西，基础最重要。