代码复杂度的警示信号

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

你需要添加“hack”来让东西继续工作。
其他开发者不断询问你某部分代码是如何工作的。
其他开发者不断误用你的代码，并导致错误。
有经验的开发者阅读一行代码需要的时间超过一瞬间。
你感到害怕修改这部分代码。
管理层认真考虑雇佣多个开发者来处理单个类或文件。
很难想出如何添加一个功能。
开发者经常争论在这部分代码中应该如何实现功能。
人们经常对这部分代码做出完全无意义的更改，你只能在代码审查期间发现，或者在更改已提交后才发现。

这些是我能立刻想到的。还有其他哪些？

-Max

评论中的其他观点

Andrew Pennebaker 说：

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

Max 回复： 是的，这些很好！尽管我不会说慢的解释/编译或需要多种语言一定是复杂度的指标。有些语言只是编译器慢，有些项目就是大，有时你必须使用多个工具来完成工作。

John 说：

“管理层认真考虑雇佣多个经理来管理处理单个类或文件的开发者”怎么样？

Max 回复： 哈哈哈！

Jerome 说：

其他几个：

你的方法参数列表随时间失控增长。
你感到需要注释控制块结尾（我称之为“if”膨胀）。
编写一个好的覆盖测试所需的代码比你要测试的方法还多。

Max 回复： 是的！这些相当好！尽管，就测试编写而言，我发现测试比代码大是相当常见的。我认为这更可能是需求复杂度的问题，而不是代码复杂度的问题。

Simon 说：

依赖树看起来像这样？ http://thedailywtf.com/Articles/Enterprise-Dependency-The-Next-Generation.aspx

Max 回复： 哈哈哈！！确实是WTF！！

Raghu 说：

读了Simon的评论后，我去了那个网站，找到了这个。 http://thedailywtf.com/Articles/Serious-String-Validation.aspx ~raghu

Palo 说：

嗨Max，我真的很喜欢你的博客文章。去年我在为一个批处理系统工作，用于从大型数据集中计算统计信息。为了添加一个新的业务规则，我必须检查和/或修改几个不相关的地方，包括spring beans、属性文件和其他东西，所有这些都很琐碎，但很容易出错（例如，有一个DB2/Oracle小数/整数问题，没有人第一次就做对）。所以我认为当一个系统很容易出错时，它就是复杂的（后果是“你感到害怕修改这部分代码”）。

Max 回复： 嘿Palo！谢谢你的好话！是的，我同意，“太容易出错”是一个非常好的点。

Srihari S 说：

如果你的代码有异味，它就是复杂的。参考WIKI：代码异味。

Steve Bush 说：

我昨天从头到尾读了《代码简洁性》！（电子书有“封面”吗？）。并且很享受！我会说大约50%我同意，剩下的50%我强烈同意！我想我可以挑剔几个点，（并期待在未来的某个日期这样做！），但总的来说，我大部分同意你的初始声明，即无论它可能是什么，它是一个开始！而且是一个非常可行的开始！

我不会介意看到一个博客/课程/午餐系列，每节课（或博客条目）提出一个规则或定律进行讨论！那将是一个有趣的对话！

我有两个与编码点无关的评论要添加：

我从书中得到的一个全新东西是物理组织。每个定律、规则、事实、定义在出现时都被标识出来，然后当我到达结尾时，我得到了一个附录，列出了每一个！这创造了整本书的绝妙回顾！我非常喜欢那个，就像在最后5分钟内几乎 mentally re-reading 整本书！太棒了！

另一个无关但可能有趣的点是我阅读的方式：通过iPad iBooks应用。我读了很多，但几乎总是通过网页浏览器。我注意到我几乎 constantly scroll 当我阅读时；在iPad上，我的拇指让文本像自动提示器一样上升，这样我的眼睛总是保持大约相同的高度；在Mac上，我阅读时两个手指放在触控板上做同样的事情。但iBooks让文本静止，我的眼睛从上到下移动。我不能说那是否优越，只是觉得不同，并提醒我们自从，它们叫什么，那些纸东西，哦是的，书！以来已经走了很长的路。

一个幽默的愚蠢：我去了一次iBook目录，它只在屏幕上显示到第2章。我花了整整五分钟试图让剩余的章节显示。页面不会翻！我几乎放弃并决定这是一个错误，当我意识到，目录可以滚动！！！！！！无论如何，你做得非常好，非常感谢！我享受了它，并且我相信我的编程将来会从中受益！

Steve————- “我们现在玩得开心！”

Vidhyut 说：

复杂的软件大多有大的依赖。所以如果你不能从一个项目重用类到另一个项目，这是一个信号，表明你有 tightly coupled 和复杂的系统。

Mike W. 说：

这个怎么样：

你的整个代码库是一个大泥球。 http://www.laputan.org/mud/mud.html

Max 回复： 信不信由你，我曾经认识一个人，他用那个特定的术语自豪且有意地描述他的系统设计，仿佛它是一个应该保留的合法设计选择。

其他技术讨论

关于AI代理输出的质量

我目前认为，AI代理可以成功生成的输出数量和质量取决于：

模型的质量。
代理的质量。
输入的质量（如提示或其他上下文）。
代理可以独立运行的确定性、客观验证的质量。

我目前认为，除非你是模型开发者，最重要的部分是“确定性、客观验证”。

简单来说，如果你告诉AI做某事，它需要某种方式能够自行验证它做了正确的事。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。

这意味着你的测试和验证工具越好，你从模型得到的输出就越好。不仅仅是测试的数量。它们必须是好的测试，有智能的断言和好的错误消息。

这也意味着代理成功涉及思考如何将任务分解成可以各自通过自动化测试、linter等客观验证的单个部分。

作为说明，输入的质量也很重要并在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎一切帮助人类编写代码的东西也帮助代理。

关于技术债务

技术债务有价值的想法大多是一个神话。当你做出一个糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那根本不是真的。它几乎立即开始。

做正确的事的成本通常是几个小时，也许一天，而且你几乎总是立即收回那个时间。也就是说，做对通常花费与做错相同的时间。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”它几乎总是结果根本没有节省你时间！它让处理变更更困惑。它让代码审查更长。它在测试期间以更困惑的方式失败，需要更长时间调试。它几乎从不节省你实际时间。

偶尔，你的路径上有一些“岩石”如此巨大，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了你能一次交付一个一天的功能。但那是技术债务决策的极小、极小部分。

这变得更疯狂，因为如果你随着进行做对一切（你总是重构系统，使其看起来像是被设计来做 exactly 它现在做的事情），那么一切始终保持相对容易。但如果你偷工减料，一切变得复合性地更困难，到点你生成“岩石”没有人能移动。不像复杂度是某种线性东西，你可以 later 投入线性时间修复。你绝对可以让自己陷入一个如此糟糕的境地，以至于你公司中没有人有时间或专业知识修复它。

这一切感觉如此无辜：“让我们 just 偷几个工减几个料，它会帮助我们 meeting 这个截止日期，”（一个截止日期通常是想象的 anyway，你可以滑几周没有后果）。“很难想出如何做对这件事，我们可以推迟它吗？”然后砰，很快你发现自己在一个沼泽中，一切都很困难，“我们不知道为什么！”

我留给你最后一件事：当我直接编码我生活的每一天时，我在这方面完全 uncompromising。我基本上 incapable 看坏代码——我必须重构它或者我不能做工作。而 somehow，我从未错过那个部分我整个职业生涯中的单个截止日期。

关于建议的质量

我估计，我看到的或被告诉的每一万条坏建议中，我收到了一条好建议。互联网充满坏建议，因为文明充满坏建议。文明充满坏建议，因为全球的教育大多不教人们思考、研究或确定什么是真实的。相反，它教人们记忆和重复事实，其中大多数不重要、不真实或无用。

所以一般来说，我们不应该惊讶互联网（尤其是社交媒体）充满不重要、不真实或无用的信息。它不是全部那样——我在网上学到了大量非常有用的东西。有大量有价值的内容。我会说，人们的观点关于事情，无论是在报纸、博客文章、论坛还是其他什么， rarely 有那种价值， though。

所以要点是什么？嗯，最好有某种方式确定某事是否重要或有用， before 你开始依赖它或向他人重复它。最简单的工具是说：“它有效吗？”这条数据可靠地帮助你完成某事吗？它100%的时间有效，还是更少？

对于许多帖子，你会发现：这条数据根本不帮助你做任何事。