《代码简洁之道：软件基础》现已免费
2022年5月16日，作者：Max Kanat-Alexander
大约一年前，一位Twitter用户在一个讨论中提到了我和其他几位编程书籍作者，描述了在他们国家获取计算机编程书籍的障碍。我之前对这些问题的了解比较有限——世界上有许多国家，一本书的美元价格可能相当于一个人整周的工资。
我写这些书的目的不是为了赚钱——我写书是为了传达信息并帮助他人。我通常认为，如果人们为一本书付费，他们更有可能真正阅读它，而重点是让人们阅读这本书，因为这是我能改善软件行业的唯一途径。
这本书仍在销售（这对计算机书籍来说很不寻常，因为它已经发布了十年），但对我来说，赚多少钱并不重要——重要的是让人们阅读这本书。
当我意识到世界上有大量人群如果必须付费就完全无法合法阅读这本书时，我与O’Reilly的编辑合作，看看我们是否能让这本书完全免费。
结果发现，由于他们无法控制的复杂原因，他们无法在亚马逊或O’Reilly商店免费提供这本书。但他们可以将这本书的分发权交给我，去掉封面，让我免费分发！
所以，你现在可以免费下载《代码简洁之道：软件基础》了！我希望这能让更多人阅读并理解软件设计的基本法则，帮助使软件开发世界变得更好。
分享
- 点击在Facebook上分享（在新窗口中打开）Facebook
- 点击在LinkedIn上分享（在新窗口中打开）LinkedIn
- 点击在Hacker News上分享（在新窗口中打开）Hacker News
- 点击在Reddit上分享（在新窗口中打开）Reddit
- 点击在Threads上分享（在新窗口中打开）Threads
- 点击在X上分享（在新窗口中打开）X
评论
sergey 说：2022年5月16日晚上9:45 现在许多编程书籍中最好的主要编程书免费了，真是太棒了。谢谢！
Max Kanat-Alexander 回复：2022年6月7日凌晨2:03 谢谢，sergey！我很高兴能以这种方式帮助人们。
STEVEN GORDON 说：2022年5月17日上午8:32 你的书中测试实际上是被事后考虑的，这告诉我你对软件开发的理解存在漏洞。自动化测试应该放在首位，而不是最后。它是表达和验证代码意图的关键（而不是那些随时间变得越来越不真实的妄想评论），通过安全重构提高简洁性，并在整个生命周期内维护代码。
Max Kanat-Alexander 回复：2022年6月7日凌晨2:03 嘿Steven。我想你可能误解了这本书的意图或其中关于测试的内容。关于这个话题有很多要说的，但我写的最好的总结在这里：https://www.codesimplicity.com/post/the-philosophy-of-testing/
murtagy 说：2023年5月26日凌晨3:21 我想你没有在测试追着你并锁定不良接口和奇怪契约的代码库中工作过
Yubraj Lama 说：2022年6月20日凌晨12:12 《代码简洁之道》中的软件设计基本法则太棒了。谢谢你，Max。
Max Kanat-Alexander 回复：2022年10月14日凌晨5:21 谢谢！
近期思考摘录
Max Kanat-Alexander · 9月17日
通常，解决软件系统问题的方法是分配软件工程师来解决问题。 将问题分配给软件工程师的危险在于他们会编写软件来解决它。 当你在软件系统中看到长期未解决的问题时，通常意味着没有人被分配去解决那个具体问题。 当你看到不必要的软件被编写时，几乎总是因为软件工程师被分配去解决某个问题，并决定编写软件是解决方法。
阅读更多 467 分享
Max Kanat-Alexander · 6月27日
我目前认为，AI代理能够成功输出的数量和质量取决于：
- 模型的质量
- 代理的质量
- 输入的质量（如提示或其他上下文）
- 代理能够独立运行的确定性、客观验证的质量
我目前认为，除非你是模型开发者，否则最重要的部分是"确定性、客观验证"。 简单来说，如果你告诉AI做某事，它需要某种方式能够自行验证它做了正确的事。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。 这意味着你的测试和验证工具越好，从模型获得的输出就越好。这不仅仅是测试数量的问题。它们必须是好的测试，具有智能断言和良好的错误信息。 这也意味着代理的成功涉及思考如何将任务分解成可以分别通过自动化测试、linter等进行客观验证的单个部分。 需要注意的是，输入的质量也很重要，并且在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会表现得更好。令人惊讶的是，几乎所有帮助人类编写代码的东西也能帮助代理。
阅读更多 2710 分享
Max Kanat-Alexander · 6月4日
技术债务有价值的想法大多是一个神话。当你做出糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。这是上限。许多人认为需要数月或数年才能看到在软件设计上偷工减料的影响，但这根本不是真的。它几乎立即开始。 做正确的事情的成本通常是几个小时，也许一天，你几乎总是立即收回这段时间。也就是说，做正确的事情通常花费的时间与做错事情花费的时间相同。 “等等，什么？这怎么可能？我们偷工减料是为了节省时间！“结果几乎总是它根本没有为你节省时间！它使得处理变更更加混乱。它使代码审查时间更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从未节省你的实际时间。 偶尔，你的路径中会有一些如此巨大的"岩石”，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了你能够一次性地交付一个一天的功能。但这只是技术债务决策中极小的一部分。 这变得更加疯狂，因为如果你在过程中一切都做对了（你总是重构系统，使其看起来像是专门为现在做的事情设计的），那么一切在整个过程中都保持相对容易。但如果你偷工减料，一切都会变得复合性地更加困难，以至于你生成了没有人能够移动的"岩石”。复杂性不是某种线性的东西，你可以稍后投入线性时间来修复。你绝对可能陷入一个如此糟糕的境地，以至于你公司中没有人有时间或专业知识来修复它。 这一切感觉如此无辜：“让我们偷工减料吧，这将帮助我们满足这个截止日期”（这个截止日期通常是虚构的，你可以推迟几周而没有任何后果）。“很难弄清楚如何正确地做这件事，我们能推迟吗？“然后砰，很快你发现自己陷入了一个沼泽，一切都很难，“我们不知道为什么！” 我最后留给你一件事：当我每天直接编码时，我在这方面完全 uncompromising。我基本上无法忍受糟糕的代码——我必须重构它，否则我无法工作。不知何故，在我整个职业生涯的那部分中，我从未错过任何一个截止日期。
阅读更多 13142 分享