代码简洁之道

理解软件 » 代码简洁性

管理同意

为了提供最佳体验，我们使用像cookies这样的技术来存储和/或访问设备信息。同意这些技术将允许我们处理数据，例如浏览行为或本网站上的唯一ID。不同意或撤回同意可能会对某些功能和特性产生不利影响。

功能性
- 始终活跃
- 技术存储或访问对于启用订阅者或用户明确请求的特定服务的合法目的是绝对必要的，或者仅用于通过电子通信网络传输通信的唯一目的。
偏好
- 技术存储或访问对于存储订阅者或用户未请求的偏好的合法目的是必要的。
统计
- 技术存储或访问专门用于统计目的。专门用于匿名统计目的的技术存储或访问。没有传票、互联网服务提供商的自愿合规或来自第三方的额外记录，仅为此目的存储或检索的信息通常无法用于识别您。
营销
- 技术存储或访问是创建用户配置文件以发送广告，或跟踪用户在网站或跨多个网站上的类似营销目的所必需的。

管理选项管理服务管理{vendor_count}供应商阅读更多关于这些目的接受拒绝查看偏好保存偏好查看偏好 Cookie政策 {title} 法律声明

代码简洁性

理解软件

2017年10月10日 by Max Kanat-Alexander

大家好。我出版了一本新书！它叫《理解软件》。

这本书包含了我自《代码简洁性》出版以来写的所有关于软件开发和团队合作的内容，加上一些从未在任何地方发表过的全新内容。事实上，它包含了我2008年写的一篇最喜欢的文章，但之前从未发表过。所以这对你来说是个惊喜。

所有内容都被编排成漂亮的布局，然后经过策划和组织，以最大限度地提高可读性。这实际上是我非常满意的东西，我期待听到你们对它的看法。

来自出版商 《理解软件》涵盖了许多编程领域，从如何编写简单代码到对编程的深刻见解，然后是如何在你所做的工作中少犯错误！你将发现软件复杂性的问题、其根本原因，以及如何使用简洁性来创建伟大的软件。你将像以前从未做过的那样检查调试，以及如何在团队合作中掌握快乐的技巧。

Max从他传奇的博客《代码简洁性》中精选了一系列精心撰写的文章、想法和建议，关于在软件行业工作和成功。Max撰写了四十三篇文章，这些文章有能力帮助你避免复杂性并拥抱简洁性，这样你就可以成为一个更快乐、更成功的开发者。

Max的技术知识、洞察力和善良，使他赢得了代码大师的地位，他的想法将激励你，并帮助刷新你应对开发者挑战的方法。

你将学到什么

看看如何将简洁和成功带入你的编程世界
复杂性的线索——以及如何构建优秀的软件
简洁性和软件设计
程序员的原则
摇滚明星程序员的秘密
Max对软件行业的看法和解读
为什么程序员很糟糕，以及如何少犯错误
用两句话概括软件设计
什么是bug？
深入调试

你可以在亚马逊、直接从出版商那里，或任何其他销售编程书籍的地方买到它。

-Max

分享点击在Facebook上分享（在新窗口中打开） Facebook 点击在LinkedIn上分享（在新窗口中打开） LinkedIn 点击在Hacker News上分享（在新窗口中打开） Hacker News 点击在Reddit上分享（在新窗口中打开） Reddit 点击在Threads上分享（在新窗口中打开） Threads 点击在X上分享（在新窗口中打开） X

3条评论留下回复

Saim Aksr 说：2017年10月19日下午5:27 有趣的文章，代码应该总是干净且可被其他开发者阅读。回复

Urvish S 说：2018年12月11日上午12:11 这对软件开发领域的新手来说将是很大的支持。回复

深入并创建你自己的解析器库 – Tech Musings By Dave 说：2024年1月3日下午12:24 […] Max Kanat Alexandar的《理解软件》是一本超级快的读物，应该成为任何新开发者（工程师）的必读材料。它提供了简单的指导方针和解决问题的方法。书中的一部分在我脑海中回荡了一年左右，“好的开发者阅读每一行代码”。我以前从未考虑过这一点。就像对于你支持的应用程序/公司，你应该理解生产环境中运行的每一行代码。这包括你使用的第三方库。所以回到2021年，我的团队正在编写一个新应用程序，可以处理各种充满工作的XML文件。（我为Getwork/LinkUp工作）[…] 回复留下回复取消回复

联系关于书：理解软件书：代码简洁性

输入你的邮箱… 订阅

Max Kanat-Alexander 6月27日我目前认为，AI代理可以成功生成的输出数量和质量取决于：

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

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

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

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

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

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

阅读更多2510分享

Max Kanat-Alexander 6月4日技术债务有价值的想法大多是一个神话。当你做出一个糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那根本不是真的。它几乎立即开始。做正确的事的成本通常是几个小时，也许一天，而且你几乎总是立即收回那个时间。也就是说，做对通常花费的时间与做错花费的时间相同。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”结果几乎总是它根本不会节省你的时间！它使处理变更更加混乱。它使代码审查时间更长。它在测试期间以更混乱的方式失败，需要更长时间来调试。它几乎从不节省你的实际时间。

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

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

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

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

阅读更多12942分享

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

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

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

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

阅读更多249分享

Max Kanat-Alexander 5月29日你对系统做的任何更改在推出时都会收到来自某人的负面反馈。这发生不是因为每个更改有什么问题，而是因为用户习惯了系统的工作方式，他们不喜欢它改变了。他们可能批评新用户界面，或有某种情感争论为什么新东西“糟糕”，但通常他们真的只是对任何更改发生感到不安。这不是什么不寻常的事；它是几乎所有人中存在的一个因素。人们倾向于有一定 appetite 愿意在一定时间内经历多少更改，如果你超出那个，他们变得不安。

重要的是识别人们的反馈是否仅仅是这种“更改厌恶” vs 关于有价值事物的真实反馈。有几种方式判断：

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

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

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

阅读更多274分享

加载更多

管理同意联系关于书：理解软件书：代码简洁性

转到顶部