代码复杂度的线索
以下是一些表明你的代码可能过于复杂的线索：
- 你必须添加“hack”来让东西继续工作。
- 其他开发者不断询问你某部分代码是如何工作的。
- 其他开发者不断误用你的代码，并导致错误。
- 有经验的开发者阅读一行代码需要超过一瞬间的时间。
- 你感到害怕修改这部分代码。
- 管理层认真考虑雇佣多个开发者来共同处理一个类或文件。
- 很难想出如何添加一个新功能。
- 开发者经常争论在这部分代码中应该如何实现某些功能。
- 人们经常对这部分代码做出完全无意义的更改，你只有在代码审查期间或在更改已提交后才能发现。
这些是我能立刻想到的。还有其他哪些呢？
-Max
评论
Andrew Pennebaker 说： 2011年11月17日下午12:14
- 代码与其他代码协作不佳（API弱或没有API）。
- 每个函数似乎都需要自定义输入类型。
- 编译或解释速度慢。
- 项目需要多种编程语言。
- 很难将项目与其依赖解耦或切换到替代库。
- 开发者讨论从头重写整个项目。
回复：Max Kanat-Alexander 说： 2011年11月17日晚上9:12 是的，这些很好！虽然我不会说慢的解释/编译或需要多种语言 necessarily 是复杂度的指标。有些语言就是有慢的编译器，有些项目就是大，有时你必须使用多个工具来完成工作。
-Max
John 说： 2011年11月17日下午12:30 “管理层认真考虑雇佣多个经理来管理处理一个类或文件的开发者”怎么样？
回复：Max Kanat-Alexander 说： 2011年11月17日晚上9:12 哈哈哈！
Jerome 说： 2011年11月17日下午12:56 其他几个：
- 你的方法参数列表随时间失控增长。
- 你感到需要注释控制块结尾（我称之为‘if’膨胀）。
- 编写一个好的覆盖测试需要的代码比你想测试的方法还多。
回复：Max Kanat-Alexander 说： 2011年11月17日晚上9:13 是的！这些相当好！虽然，就测试编写而言，我实际上发现测试比代码大是很常见的。我认为那可能更多是需求复杂度的问题，而不是代码复杂度的问题。
-Max
Simon 说： 2011年11月17日下午5:32 依赖树看起来像这样？ http://thedailywtf.com/Articles/Enterprise-Dependency-The-Next-Generation.aspx
回复：Max Kanat-Alexander 说： 2011年11月17日晚上9:13 哈哈哈！！确实WTF！！
-Max
Raghu 说： 2011年11月17日晚上9:54 读了上面Simon的评论后，我去了那个网站，找到了这个。 http://thedailywtf.com/Articles/Serious-String-Validation.aspx ~raghu
Palo 说： 2011年11月29日凌晨1:02 嗨Max，我真的很喜欢你的博客文章。去年我在为一个批处理系统工作，用于从大数据集计算统计信息。为了添加一个新的业务规则，我必须检查和/或修改几个不相关的地方，包括spring beans、属性文件和其他东西，所有这些都很琐碎，但很容易出错（例如，有一个DB2/Oracle decimal/integer问题，没有人第一次就做对）。所以我认为一个系统复杂时，很容易出错（后果是“你感到害怕修改这部分代码”）。
回复：Max Kanat-Alexander 说： 2011年11月29日凌晨1:16 嘿Palo！谢谢你的好话！是的，我同意，“太容易出错”是一个非常好的点。
-Max
Srihari S 说： 2012年4月6日凌晨1:24 如果你的代码有味道，它就是复杂的。参考WIKI：代码味道。
Steve Bush 说： 2012年4月7日晚上11:36 我昨天从头到尾读了《代码简洁性》！（电子书有“封面”吗？）。并且很享受！我会说大约50%我同意，剩下的50%我强烈同意！我想我可以挑几个点，（并期待在将来的某个时候这样做！），但总的来说，我 mostly 同意你的初始声明，即无论它可能是什么，它是一个开始！并且是一个非常可行的开始！
我不介意看到一个博客/课程/午餐系列，每节课（或博客条目）提出一个规则或定律进行讨论！那将是一个有趣的对话！
我有两个与编码点无关的评论要添加：
我从书中得到的一个全新的事情是物理组织。每个定律、规则、事实、定义在出现时都被标识，然后当我到达结尾时，我得到了一个附录，列出了每一个！这创造了整本书的 fantastic 回顾！我非常喜欢那个，它就像扫描，几乎 mentally 重读，整本书在最后5分钟！太棒了！
另一个无关但可能有趣的点是我阅读它的方式：通过iPad iBooks应用。我读得非常多，但几乎总是通过网页浏览器。我注意到我 pretty constantly 滚动当我阅读；在iPad上，我的拇指保持文本像自动提词器一样上升，所以我的眼睛总是保持大约相同的高度；在Mac上，我阅读时两个手指放在触控板上做同样的事情。但iBooks保持文本静止，我的眼睛从上到下移动。我不能说那是否 superior，它只是 struck 我不同，并提醒我们自从，它们叫什么，那些纸东西，哦是的，书！以来已经走了很长的路。
一个幽默的愚蠢：我去了一次iBook目录，它只在屏幕上显示到第2章。我花了整整五分钟试图让剩余的章节显示。页面不会翻！我几乎放弃并决定它是一个错误，当我意识到，目录可以滚动！！！！！！无论如何，你做得非常好，非常感谢！我享受了它，并且我确定我的编程将来会从中受益！
Steve ————- “我们现在玩得开心！”
Vidhyut 说： 2013年3月18日下午5:33 复杂软件 mostly 有大的依赖。所以如果你不能从一个项目重用类到另一个项目，它是一个信号，你有一个 tightly coupled 和复杂的系统。
Mike W. 说： 2017年9月21日晚上9:35 这个怎么样：
- 你的整个代码库是一个大泥球。 http://www.laputan.org/mud/mud.html
回复：Max Kanat-Alexander 说： 2017年9月24日晚上11:15 信不信由你，我曾经认识一个人，他用那个 specific 术语自豪地、 intentionally 描述他的系统设计，仿佛它是一个应该被保留的合法设计选择。
Max Kanat-Alexander 的最新思考
6月27日
我目前认为，AI代理可以成功生成的输出的数量和质量取决于：
- 模型的质量。
- 代理的质量。
- 输入的质量（如提示或其他上下文）。
- 代理可以独立运行的确定性、客观验证的质量。
我目前认为，除非你是模型开发者，否则最重要的部分是“确定性、客观验证”。
简单来说，如果你告诉AI做某事，它需要某种方式能够验证它做了正确的事，靠自己。在软件中，这通常意味着运行一个测试、一个linter等，如果系统做错了就会失败。
这意味着你的测试和验证工具越好，你从模型得到的输出就越好。这不只是关于测试的数量。它们必须是好的测试，有智能的断言和好的错误消息。
这也意味着代理成功涉及思考如何将任务分解成 individual pieces，每个都可以通过自动化测试、linters等客观验证。
作为说明，输入的质量也很重要，并在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎一切帮助人类编写代码的东西也帮助代理。
6月4日
技术债务有价值的想法 mostly 是一个神话。当你做出一个糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那 simply 不是真的。它几乎立即开始。做正确的事的成本通常是几小时，也许一天，你几乎总是立即 recover 那个时间。也就是说，它通常最终花费做对的时间与做错的时间相同。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”它几乎总是 turns out 它根本不节省你的时间！它使处理变更更加混乱。它使代码审查更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从不节省你实际时间。
偶尔，你的路径中有一些“岩石”如此巨大，你 simply 无法移动它。没有人应该花费三个月设计一个新工具，只是为了你可以 shipping 一个一天的功能，一次。但那是技术债务决策的 tiny, tiny 部分。
这变得甚至更疯狂，因为如果你 as you go 做对一切（你总是重构系统，使其看起来像是设计来做 exactly 它现在做的事情），那么一切在整个时间保持 relatively 容易。但如果你偷工减料，一切变得 compoundingly 更困难，到点你 generate “岩石”没有人可以移动。不像复杂度是某种线性东西，你可以然后 later 回去 invest 一个线性量的时间来修复。你绝对可以让自己陷入一个如此糟糕的情况，nobody 在你的公司有时间或 expertise 来修复它。
它 all feels so innocent：“让我们 just 偷几个工减几个料，它会帮助我们 meet 这个截止日期，”（一个截止日期通常是 imaginary anyway，你可以 slip 几周没有后果）。“很难想出如何做对这个，我们可以 punt on it？”然后 bam，非常 quickly 你发现自己在一个沼泽中，一切都很困难，“我们不知道为什么！”
我留给你最后一件事：当我直接编码我生命的每一天时，我对此 completely uncompromising。我基本上 incapable 看坏代码—我必须重构它或我不能做工作。并且 somehow，我从未错过一个单一截止日期在我整个职业生涯的那部分。
5月30日
我估计，我每看到或被告诉一万条坏建议，才收到一条好建议。互联网 full of 坏建议，因为文明 full of 坏建议。文明 full of 坏建议，因为整个星球的教育 mostly 不教人们思考、学习或 determine 什么是真的。相反，它教人们记忆和重复事实，大多数不重要、不真实或无用。
所以一般来说，我们不应该 surprised 互联网（和社交媒体 particularly）full of 信息不重要、不真实或无用。它不是 all that way—我 online 学到了非常大量的非常有用的东西。有 huge amount 有价值的内容。我会说，人们的_opinions_关于事情，无论是在报纸、博客文章、论坛或无论什么， rarely 有那个价值， though。
所以 takeaway 是什么？嗯，最好有某种方式 determine 如果某事重要或有用， before 你开始 rely on it 或 repeat it to others。最简单的工具是说：“它工作吗？”这个数据 reliably 帮助你完成某事吗？它工作100%的时间，或更少？
对于许多帖子，你会发现：这个数据根本不帮助你做任何事。
5月29日
你对系统做的任何更改都会收到负面反馈从_somebody_当你推出它时。这发生不是因为每个更改有什么问题，而是因为用户习惯了系统工作的方式，并且他们不喜欢_它改变了_。他们可能批评新用户界面，或有 some emotional argument 关于为什么新东西“sucks，”但 often 他们真的 just upset 任何更改发生了 at all。这不是什么不寻常的；它是一个因素存在于几乎所有人类。人们 tend to 有某种 appetite for 多少更改他们愿意 experience 在一段时间内，如果你超越 that，他们变得 upset。
重要的是 recognize 当人们的反馈 simply 是这个“变更厌恶” vs. 真实反馈关于某事 valuable。有几种方式告诉：
- 变更厌恶 usually 持续3到10天。如果你收到反馈从一个用户 within 第一个3到10天后你推出一个更改，并且那个相同反馈不被提供由一个 huge number 你的用户，它 worth considering 是否用户的响应 just 变更厌恶。
- 变更厌恶反馈 often emotional。它可能是侮辱性的。它可能表达为 just 一个意见（“新菜单的颜色丑陋”） vs 一个事实（“我测量了，新工具比旧工具慢10倍。”）。
你试图避免，当管理变更时，是创建_so_ much 变更厌恶以至于你引起一个反抗。一个反抗基本上看起来像_so_ many 人们变得愤怒以至于他们去你的管理层并且他们停止你的工作。当有疑问时，推出 smaller 更改到 fewer 人们以 slower 速率扩张。随着时间的推移，你将学习多少变更你可以推出，多快。永远， ever 做一个“大爆炸”发布，所有你的用户 experience massive 变更 all at once。
现在，所有这个 said，永远 attribute_all_反馈到“变更厌恶。”Often 人们 do 有反馈是合法的。如果许多人们提供你相同 factual 反馈，并且你看它和他们的反馈 makes sense 并且你认为修复它会改进产品，那 very likely not 变更厌恶。Plus，说“这只是变更厌恶”不意味着你应该 totally 忽略反馈。你应该至少 acknowledge it，让人们知道他们被听到。它_does_ 意味着你不应该 argue with the person 或 try to reason with them about it，因为他们 having an emotional reaction 哪里你 trying to “logic” them out of it 不会帮助 anybody。如果你认为它是变更厌恶，你 acknowledge them，并且他们 just keep fighting with you，有时你应该 just ignore them 并且 get on with doing your job。如果他们回来3天后有一个更 reasoned argument，然后你知道它不是 just 变更厌恶，并且 also 他们 probably being more helpful by then, anyway。