代码简洁性：软件开发的科学
2012年3月28日，作者：Max Kanat-Alexander
如果每位软件开发者都能获得长期经验的知识，而无需经历反复失败的痛苦会怎样？如果软件开发过程不再是持续混乱的复杂性和争论，而是每个程序员都能理解的理智、有序的进展会怎样？如果所有程序员及其经理在讨论软件开发决策时有一个共同的基础——一个基于事实而非观点或权威，并且在实际日常软件项目中真正有帮助的共同基础会怎样？
如果软件开发是一门科学——拥有定律、规则、事实和定义，能明确告诉你该走哪些方向、该避免哪些方向会怎样？不是限制你只能使用某种特定方法的教条系统，而是一系列让你自由思考并为自己的情况做出正确决策的原则会怎样？
如果所有这些都写在一本书里，这本书只有90页，并且软件行业的每个人——无论是不是程序员——都能理解会怎样？这会让世界变得不同吗？亲自发现吧：《代码简洁性：软件开发的科学》。
过去几年，我一直在开发、测试和完善一系列软件开发的科学定律。我做的部分工作，你在这个博客中已经看到，但这本书不仅仅是这些文章的重复。它是关于这门新科学的完整、有组织的论述——一系列原则，我希望不仅能改变你的软件，还能为你作为软件开发者的生活带来理智、秩序和快乐。然后，一旦你的团队阅读了它，它将为你们团队的方向和讨论带来理解和洞察。最后，当每个软件开发者都阅读了它，它将改变软件开发的世界。
但这一切从这里开始，从你开始。帮助我改变世界。你只需要读一本书，然后如果你觉得有所收获，告诉其他人，也许他们也会读。
直接来自O’Reilly，提供印刷版和所有电子阅读器版本，截至4月4日享受50%折扣。在Kindle商店有售，印刷版也可在众多其他在线书店购买。
-Max
评论
Matt Doar 说：
2012年3月28日下午2:49
我已经订购了我的副本！
回复：
Max Kanat-Alexander 说：
2012年5月9日下午9:47
太棒了！
Alex Vincent 说：
2012年3月28日下午10:37
它已经在我的亚马逊购物车里了。
Reilly Sweetland 说：
2012年3月29日上午8:14
我上周末买了这本书，几乎快读完了。仅仅因为一个简单的软件设计决策，它已经可能节省了未来50小时的维护麻烦。花在规划和设计软件上的时间是值得的。花在学习软件设计上的时间更是成倍地值得。干得好，Max——谢谢你！
回复：
Max Kanat-Alexander 说：
2012年5月9日下午9:47
哇，太棒了。哈哈，关于花时间学习软件设计的观点很好！-Max
Ash 说：
2012年4月1日下午10:12
订购我的副本。谢谢！
回复：
Max Kanat-Alexander 说：
2012年5月9日下午9:47
哇哦！
Ahmed 说：
2012年4月3日下午10:43
恭喜Max。
好工作，我马上订购我的电子版，真主保佑。
谢谢，
Ahmed。
回复：
Max Kanat-Alexander 说：
2012年5月9日下午9:46
谢谢Ahmed！太好了！
Arun Saha 说：
2012年4月7日上午10:01
从O’Reilly买了电子书，开始阅读，很享受！
回复：
Max Kanat-Alexander 说：
2012年5月9日下午9:46
太棒了！
Alex Vincent 说：
2012年4月30日下午9:30
如果你在旧金山湾区，我能安排签名吗？
这是一本相当好的书，但是：“不够长；一天读完”:p（开玩笑，长度很好。Coding Horror的Jeff Atwood可能也会喜欢这本书。）
回复：
Max Kanat-Alexander 说：
2012年5月9日下午9:46
嘿Alex！我在湾区。如果Jeff读了我会很高兴，我很想知道他的想法。不过，我希望他读的是几天后要出的修订版，而不是当前版本。-Max
Albert 说：
2012年5月10日下午12:02
Max，如果我买Kindle版本，会自动得到修订版吗？
回复：
Max Kanat-Alexander 说：
2012年5月12日下午6:31
嘿Albert！实际上，我不确定；这是我的第一次修订，所以我不知道它是如何工作的。至少，当你购买Kindle版本时，有机会以5美元的价格“升级”到O’Reilly的无DRM版本，使用书末出现的链接。O’Reilly版本肯定能免费更新。
Ken Penn 说：
2012年6月6日下午12:12
听完网络直播后买了我的副本。我之后立即写代码，仅仅听讲就帮助我把函数做得更简单了一点。
Ken Penn 说：
2012年6月6日下午12:13
Max——请发布你何时举行聚会，我在湾区。
Robert McClain 说：
2012年9月25日上午2:15
一个有趣的讨论值得评论。我认为你应该多写这个主题，它可能不是一个禁忌话题，但通常人们不够多谈论这样的话题。干杯。
Lynn Maddox 说：
2012年10月17日上午2:04
Max Kanat-Alexander的《价值便利》（由O’Reilly于2012年出版）是那种你可能会与年轻或熟练的设计师分享并说：“花几天时间读这个，然后周四我们讨论你的风格”的指南。有许多可引用的段落、精辟的格言和作为解释、信息、指南和规则方式的公理。
JavaScript Resources | brianbar.net 说：
2015年8月5日下午12:57
[…]初始时间最好花在学习快速掌握事物上，借助像《代码简洁性》、《实用思维与学习》、《企业应用架构模式》和[…]这样的书籍。
What is Data Science? – Data On Scale 说：
2016年1月15日上午4:07
[…]没有一个清晰科学的定义方法，就像计算机科学、软件开发科学和许多其他学科一样。所以我决定写这篇文章，期望能产生一些发现[…]
Code Simplicity: The Science of Software Development – coding | factory 说：
2018年12月22日下午6:48
[…]推文[…]
最新思考
Max Kanat-Alexander，6月27日
我目前认为，AI代理能够成功生成的输出数量和质量取决于：
- 模型的质量。
- 代理的质量。
- 输入的质量（如提示或其他上下文）。
- 代理可以独立运行的确定性、客观验证的质量。
我目前认为，除非你是模型开发者，否则最重要的部分是“确定性、客观验证”。
简单来说，如果你告诉AI做某事，它需要某种方式能够自行验证它做对了。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。
这意味着你的测试和验证工具越好，从模型得到的输出就越好。不仅仅是测试的数量。它们必须是好的测试，具有智能断言和良好的错误消息。
这也意味着代理的成功涉及思考如何将任务分解成可以分别通过自动化测试、linter等客观验证的单个部分。
需要注意的是，输入的质量也很重要，并且在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会表现得更好。令人惊讶的是，几乎一切帮助人类编写代码的东西也帮助代理。
阅读更多 2310 分享
Max Kanat-Alexander，6月4日
技术债务有价值的想法大多是个神话。当你做出糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。这是上限。许多人认为需要数月或数年才能看到在软件设计上偷工减料的影响，但这根本不是真的。它几乎立即开始。做正确事的成本通常是几小时，也许一天，而你几乎总是立即收回那段时间。也就是说，做对事通常花费与做错事相同的时间。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”结果几乎总是它根本不会节省你的时间！它使处理变更更加混乱。它使代码审查时间更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从不节省实际时间。
偶尔，你的路径上会有一些如此巨大的“岩石”，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了交付一个一次性的、一天的功能。但那是技术债务决策中极小的一部分。
这变得更疯狂，因为如果你随着进展做对一切（你总是重构系统，使其看起来像是为现在做的事情设计的），那么一切在整个过程中都保持相对容易。但如果你偷工减料，一切会变得越来越困难，以至于你产生了没有人能移动的“岩石”。复杂性不是某种线性的东西，你可以后来投入线性时间修复。你绝对可能陷入一种如此糟糕的情况，以至于你公司里没有人有时间和专业知识来修复它。
这一切感觉如此无辜：“让我们偷点工减点料，它会帮助我们赶上这个截止日期”（这个截止日期通常是虚构的，你可以推迟几周而没有任何后果）。“很难弄清楚如何做对，我们能推迟吗？”然后砰，很快你发现自己陷入沼泽，一切都变得困难，而“我们不知道为什么！”
我最后留给你一件事：当我直接编码的每一天，我对此完全 uncompromising。我基本上无法忍受糟糕的代码——我必须重构它，否则我无法工作。不知何故，在我整个职业生涯的那部分，我从未错过一个截止日期。
阅读更多 12940 分享
Max Kanat-Alexander，5月30日
我估计，我看到的或被告知的每一万条坏建议中，只有一条好建议。互联网充满坏建议，因为文明充满坏建议。文明充满坏建议，因为全球的教育大多不教人们思考、研究或确定什么是真实的。相反，它教人们记忆和重复事实，其中大多数是不重要、不真实或无用的。
所以总的来说，我们不应该惊讶互联网（尤其是社交媒体）充满了不重要、不真实或无用的信息。并非全部如此——我在网上学到了大量非常有用的东西。有大量有价值的内容。不过，我要说，人们对事物的观点，无论是在报纸、博客文章、论坛还是其他地方，很少具有那种价值。
那么，要点是什么？嗯，最好有某种方式在开始依赖或向他人重复某事之前确定它是否重要或有用的。最简单的工具是说：“它有效吗？”这条数据是否可靠地帮助你完成某事？它100%有效，还是更少？
对于许多帖子，你会发现：这些数据根本无助于你做任何事。
阅读更多 249 分享
Max Kanat-Alexander，5月29日
你对系统所做的任何更改在推出时都会收到某人的负面反馈。这发生不是因为每次更改都有问题，而是因为用户习惯了系统的工作方式，他们不喜欢它改变了。他们可能会批评新的用户界面，或者有一些关于新东西“糟糕”的情感争论，但通常他们真的只是对任何改变发生感到不安。这不是什么不寻常的事；这是几乎所有人中都存在的因素。人们往往对在一段时间内愿意经历多少改变有一定的胃口，如果你超出了那个范围，他们会感到不安。
重要的是要识别人们的反馈是简单的这种“变更厌恶”还是关于有价值事物的真实反馈。有几种方法可以判断：
- 变更厌恶通常持续3到10天。如果你在推出变更后的前3到10天内收到用户的反馈，并且同一反馈没有被大量用户提供，值得考虑用户的反应是否只是变更厌恶。
- 变更厌恶反馈通常是情感化的。它可能是侮辱性的。它可能只是表达为一种观点（“新菜单的颜色很丑”）而不是事实（“我测量了，新工具比旧工具慢10倍”）。
在管理变更时，你要避免的是制造如此多的变更厌恶，以至于引起反抗。反抗基本上看起来像是如此多的人生气，以至于他们去找你的管理层并阻止你的工作。如有疑问，向更少的人推出更小的变更，扩展速度更慢。随着时间的推移，你将了解可以推出多少变更，多快。永远不要做“大爆炸”发布，让所有用户一次性经历巨大变更。
现在，所有这些 said，永远不要将所有反馈归因于“变更厌恶”。通常人们确实有合法的反馈。如果许多人提供相同的 factual 反馈，你看了觉得他们的反馈有道理，并且你认为修复它会改进产品，那很可能不是变更厌恶。另外，说“这只是变更厌恶”并不意味着你应该完全忽略反馈。你至少应该承认它，让人们知道他们被听到了。它确实意味着你不应该与那个人争论或试图与他们讲道理，因为他们正在经历情感反应，你试图用“逻辑”说服他们不会帮助任何人。如果你认为是变更厌恶，你承认他们，而他们只是继续与你争吵，有时你应该忽略他们，继续做你的工作。如果三天后他们带着更合理的论点回来，那么你知道那不仅仅是变更厌恶，而且他们那时可能也更有帮助了。
阅读更多 274 分享
加载更多