代码简洁性第二版

2012年8月22日，Max Kanat-Alexander发布了《代码简洁性》的第二版修订。最重要的变化是本书现在更快地深入软件设计的法则和规则。它以一个完全重写的序言开始，讲述了作者如何开发《代码简洁性》中的原则，以及读者可能对它们感兴趣的原因。然后进入一个更短的第一章，将旧版第一章的所有内容浓缩为几页，跳过了旧的第二章（关于某物成为科学的漫长讨论），直接进入法则部分。

如果您读过原始版本，作者非常希望听到您对新修订版起始内容的反馈！

附言：如果您从O’Reilly购买了电子书，您可以免费获得每个新修订版，而且可能还会有比这更多的修订！如果您从其他地方获得了电子书，书中有一个小链接，可以让您以相当便宜的价格“升级”到O’Reilly版本，这样您也可以免费获得这个修订版和所有未来的修订版。作者不偏袒任何特定的购书方式，但O’Reilly版本绝对是获取新修订版的最佳方式。

Kevin (2014年5月22日): 疯狂了！亚马逊发货更快，所以我选择了那条路。我喜欢电子书，但根据我读过的您的材料，我想确保我能对重点做注释。现在我在想，我应该花几块钱买两本，在等待印刷版发货时读电子书。假设电子书是即时下载的。我的书有67页，所以我一定买了原始版本。从O’Reilly买吧，教训 learned。——Kevin
Max Kanat-Alexander (2014年8月24日): 疯狂大学！是的，电子书是即时下载的。我认为两种格式都有很好；我可以在手机上获取电子书，如果需要的话可以展示给别人看，但有时实体书对人们来说更“真实”。我想序言中会说明是哪个修订版。如果有说明我删除了整个章节的注释，那就是第二版。——Max
其他引用评论: 包括来自Christiaan Molendijk和coding | factory的引用和链接。

最新博文摘要

2025年6月27日: AI代理输出的关键因素

作者目前认为，AI代理能成功生成的输出数量和质量取决于：

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

除非您是模型开发者，否则最重要的部分是“确定性、客观验证”。简单来说，如果您告诉AI做某事，它需要某种方式能够自行验证它做了正确的事。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。

这意味着您的测试和验证工具越好，从模型获得的输出就越好。不仅仅是测试的数量，它们必须是好的测试，具有智能断言和良好的错误消息。这也意味着代理成功涉及如何将任务分解为可以被自动化测试、linter等客观验证的单个部分。

需要注意的是，输入的质量也很重要，并且在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会表现得更好。令人惊讶的是，几乎所有帮助人类编写代码的东西也帮助代理。

2025年6月4日: 技术债务的真相

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

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

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

这变得更疯狂，因为如果您在过程中做对一切（您总是重构系统，使其看起来像是设计来做现在做的事），那么一切在整个过程中保持相对容易。但如果您偷工减料，一切变得复合性更困难，以至于您生成没人能移动的“巨石”。复杂性不是某种线性事物，您可以后来回去投入线性时间修复。您绝对可以陷入一种如此糟糕的情况，以至于公司中没有人有时间或专业知识来修复它。

这一切感觉如此无辜：“让我们偷工减料吧，它会帮助我们满足这个截止日期”（一个通常是虚构的截止日期，您可以推迟几周而没有任何后果）。“很难弄清楚如何做对，我们可以推迟吗？”然后砰，很快您发现自己陷入一个沼泽，一切都困难，而且“我们不知道为什么！”

最后一点：当作者每天直接编码时，作者对此完全 uncompromising。作者基本上无法看坏代码——必须重构它，否则无法工作。不知何故，在作者整个职业生涯的那部分，作者从未错过一个截止日期。

2025年5月30日: 互联网建议的质量

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

所以总的来说，我们不应惊讶互联网（尤其是社交媒体）充满不重要、不真实或无用的信息。并非全部如此——作者在线学到了大量非常有用的东西。有大量有价值的内容。作者会说，人们对事物的意见，无论是在报纸、博客文章、论坛还是其他什么，很少具有那种价值。

那么要点是什么？最好在开始依赖或向他人重复某事之前，有某种方式确定它是否重要或有用的。最简单的工具是说：“它有效吗？”这条数据可靠地帮助您完成某事吗？它100%有效，还是更少？对于许多帖子，您会发现：这些数据根本无助于您做任何事。

2025年5月29日: 处理变更厌恶

您对系统所做的任何更改在推出时都会收到某些人的负面反馈。这不是因为每个更改都有问题，而是因为用户习惯了系统的工作方式，他们不喜欢它改变了。他们可能批评新用户界面，或有某种情感论点关于新东西为什么“烂”，但通常他们真的只是对任何更改发生感到不安。这不是不寻常的；它是几乎所有人类中存在的一个因素。人们往往对在一定时间内愿意经历多少变更有某种胃口，如果您超出那个，他们会不安。

重要的是识别人们的反馈是简单的“变更厌恶”还是对有价值事物的真实反馈。有几种方式可以判断：

变更厌恶通常持续3到10天。如果您在推出更改后的前3到10天内从用户那里收到反馈，并且同一反馈不是由大量用户提供的，值得考虑用户的响应是否只是变更厌恶。
变更厌恶反馈通常是情感的。它可能是侮辱性的。它可能表达为只是意见（“新菜单的颜色丑”）vs事实（“我测量了，新工具比旧工具慢10倍”）。

在管理变更时，您要避免的是创建如此多的变更厌恶以至于引起反抗。反抗基本上看起来像如此多的人生气以至于他们去找您的管理层并停止您的工作。如有疑问，向更少的人推出更小的更改，以较慢的扩展速率。随着时间的推移，您将学会可以推出多少变更，多快。永远不要做“大爆炸”发布，让所有用户一次经历大规模变更。

现在，所有这些 said，永远不要将所有反馈归因于“变更厌恶”。通常人们确实有合法的反馈。如果许多人提供您相同的事实反馈，并且您看它，他们的反馈有道理，您认为修复它会改进产品，那很可能不是变更厌恶。此外，说“这只是变更厌恶”并不意味着您应该完全忽略反馈。您至少应承认它，让人们知道他们被听到了。它确实意味着您不应与那个人争论或尝试与他们推理，因为他们正在有情感反应，您尝试用“逻辑”说服他们无济于事。如果您认为是变更厌恶，您承认他们，他们只是继续与您斗争，有时您应该忽略他们并继续做您的工作。如果他们3天后带着更合理的论点回来，那么您知道不只是变更厌恶，而且他们可能那时更有帮助。