软件即知识 » 代码简洁性

管理同意

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

功能性

始终活跃
技术存储或访问严格对于启用订阅者或用户明确请求的特定服务的合法目的是必要的，或仅用于通过电子通信网络传输通信的唯一目的。

偏好

技术存储或访问对于存储订阅者或用户未请求的偏好的合法目的是必要的。

统计

技术存储或访问专门用于统计目的。技术存储或访问专门用于匿名统计目的。没有传票、互联网服务提供商的自愿合规或来自第三方的额外记录，仅为此目的存储或检索的信息通常不能用于识别您。

营销

技术存储或访问需要创建用户配置文件以发送广告，或在网站或跨多个网站上跟踪用户用于类似营销目的。

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

代码简洁性

软件即知识

2012年5月10日 by Max Kanat-Alexander

我不常深入探讨代码简洁性的哲学基础，但我越来越意识到，这些写作背后有一些哲学原则值得分享。此外，其中一些哲学直到我长时间沉浸在工作中、在许多情况下应用它、并与许多人讨论后，才完全形成。这个——一个我逐渐发展的关于软件如何在头脑中被思考和操作的理论——已经在我脑海中酝酿了相当长一段时间。是时候至少在博客文章中“纸上谈兵”地写出至少一部分了。所以，请看：

软件，从根本上说，是一个由知识构成的固体对象。它遵循知识的所有规则和定律。它在几乎所有给定情况下的行为都与知识的行为完全相同，只是它以具体形式存在。例如，当软件复杂时，它往往被误用。当软件错误（即，有bug）时，它往往导致损害或问题。当人们不理解某些代码时，他们往往错误地修改它。人们可以说这些关于知识的事情，就像可以说关于软件的事情一样。坏数据导致人们行为不当；坏代码导致计算机行为不当。我不是说计算机和人可以比较——我是说软件和知识可以比较。

人们希望以合理和逻辑的形式拥有知识。类似地，人们也应该希望以合理和逻辑的形式拥有软件——尤其是代码。因为代码是知识，它应该在查看时几乎立即转化为人们头脑中的知识。如果没有，那么它的某些部分太复杂了——可能是底层编程语言或系统，但更可能是代码设计师创建的结构。

当我们渴望知识时，有许多方式可以获取它。人们可以阅读、思考、进行观察、做实验、讨论等。总的来说，我们可以将这些方法分为自己获取数据（通过观察、实验、思考等）或从别人那里获取数据（阅读、讨论等）。

有些情况下我们必须自己获取数据，特别是当它以某种独特方式适用于我们，我们不能依赖别人正确解决时。作为一个极端例子，当我身体小得多时，用我自己的腿走路可能进行了大量的个人实验。我可能有一些帮助，但那个知识必须由我发展。

然而，有更多情况我们必须依赖二手数据。如果一个人想在生活中做好工作，有很多要知道——一个人根本不可能自己获取这么多信息。这就是别人帮助的地方：他们知道的数据，他们学到的教训并能教给我们。

这些相同原则似乎描述了何时应该自己编写代码或使用现有代码。你几乎不可能自己编写所有代码到硬件级别，并想出我们今天拥有的一些最有用的软件。当然，有些东西只有我们独特有资格编写——通常是我们正在工作的产品的特定逻辑。但有更多东西我们必须依赖现有代码，就像我们必须依赖现有二手知识作为个体生存一样。

我们可能也可以用这个原则来决定如何在开发人员之间分配工作。某个人从他们的第一手知识创建一段代码会更快，还是一群人查看现有系统（二手知识）并开始贡献他们自己的部分（随着时间的推移， essentially become their firsthand knowledge）会更快？答案显然取决于情况，尽管这里的基本想法可能不太新颖（一些程序员已经比其他人更了解系统，所以他们更快），但我们得出这个想法的方式很重要。我们首先理论化软件是知识，然后突然我们可以看到一条清晰的逻辑线到一些已知普遍正确的现有原则。非常方便，并表明我们可能可以从这个原则推导出其他更有用的信息。

当然，这本身不是科学或科学系统。它只是一个想法，一个似乎能很好地推导开发原则的想法。事实上，我会说这是我能发展的关于软件的最广泛的哲学理论之一。它似乎覆盖所有方面并解释所有行为。我实际上可以坐在这里整天理论化这个想法，但我不在这里漫谈，只是给出一个简要总结，然后看看你有什么要说的。

-Max

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

7条评论 留下回复

Mars 说：2012年5月11日上午12:48 嗨，Max 好帖子！ 我想分享的是，软件开发者/设计师应该花更多时间学习哲学知识，这对我们设计和制作知识到高质量代码的好软件非常有用。软件作为知识，它需要来自超人和超心智。 谢谢 Mars 回复

Mike W. 说：2017年7月25日下午6:35 有趣的观点。我略有不同：我认为所有软件都由决策组成，没有别的。 （决策是更具体的知识类型。） 当然，你可以提议所有知识直接来自决策，在这一点上它会变得无意义。（确实可能是这样，既然我们在哲学上讨论。）但我认为将软件称为“决策”更好，因为它更强调那些决策的可变性。相比之下，大多数人将“知识”视为来自外部且无法改变的东西。（世界上最高的山是____，它高____英尺。）另一方面，决策可以更难或更容易改变。所以它给出了更清晰的内涵。 建立在芯片设计师、固件设计师、操作系统设计师、编译器作者、语言设计师的决策之上……你将你自己的决策放入计算机，结果就是软件。（如果你不理解例如语言设计师的决策，结果就是语法错误。） “黑客”然后可以定义为“做出新决策而不是检查和修复旧决策。”我认为，这就是“让它永不回来”的要点。（http://www.codesimplicity.com/post/make-it-never-come-back/） 像你一样，我可以坐在这里整天从这个原则推断，但我只是想沟通对我来说是理解所有计算机事物的基本工作原则。 回复

Max Kanat-Alexander 说：2017年7月26日下午9:29 当然。我知道你和我之前也当面谈过这个。 我认为将其视为知识更简单，因为大多数人不会真正理解如何处理“决策”，但人们有很多处理知识的经验。如果你指出一个程序就像一本大书，一百个人同时在写（我找到的唯一好类比向非程序员解释有组织的编程），那么人们理解问题。它不仅仅解决问题——它适用于向他人沟通解决方案。 你必须思考的是，大多数编程涉及使用现有系统，而不是制作新系统。“决策”是你做的事情（从大多数人的视角），但软件对大多数程序员来说是他们拥有的东西。所以将其视为“知识”更简单，这是你拥有的东西。 关于这个我可以说更多，但可能下次见你时更容易讨论。 -Max 回复

Mike W. 说：2017年7月26日下午9:47 听起来很棒！你的观点对于广泛理解性有道理。 回复

Sandeep yadav 说：2018年5月28日上午3:04 是的当然，哲学知识在实际编码之前很重要。 回复

软件即知识 – coding | factory 说：2018年12月22日下午6:48 […] 电子邮件 […] 回复

bradapp 说：2020年7月11日上午11:49 仅供参考——这个引用/结论的来源（据我回忆）来自Phil Armour在90年代末，并在2000年8月CACM的“软件业务”专栏开篇发表，后来在他的书《软件过程法则》中。“软件不是产品。它是……存储可执行知识的媒介。……因此软件开发是知识创造活动！……或者反过来，减少无知的活动[学习]” URL: http://www.corvusintl.com/CaseforaNewBusinessModel.pdf 书: http://www.amazon.com/Laws-Software-Process-Production-Management/dp/0849314895/ 另见（来自Phil Armour）：* “5阶无知” — http://www.corvusintl.com/CACM002-5OI.htm * “项目的精神生活” — cacm.acm.org/magazines/2002/1/7171-the-spiritual-life-of-projects/fulltext | http://www.corvusintl.com/CACM007-SpiritualLife2.htm (www.researchgate.net/publication/220422468_The_Spiritual_Life_of_Projects) 回复 留下回复取消回复

联系 关于 书：理解软件 书：代码简洁性 输入您的电子邮件… 订阅

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

1. 模型的质量。
2. 代理的质量。
3. 输入的质量（如提示或其他上下文）。
4. 代理可以独立运行的确定性、客观验证的质量。 我目前认为，除非你是模型开发者，最重要的部分是“确定性、客观验证”。 简单来说，如果你告诉AI做某事，它需要某种方式能够验证它做了正确的事，靠自己。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。 这意味着你的测试和验证工具越好，你从模型得到的输出就越好。不仅仅是测试数量。它们必须是好的测试，有智能断言和好的错误消息。 这也意味着代理成功涉及思考如何将任务分解成可以各自通过自动化测试、linter等客观验证的单个部分。 作为说明，输入的质量也很重要并在我们控制之下。如果我们写更好的文档和更清晰的代码，代理做得更好。令人惊讶的是，几乎一切帮助人类写代码的东西也帮助代理。 阅读更多 2010 分享

Max Kanat-Alexander 6月4日 技术债务有价值的想法 mostly a myth。当你做出糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那 simply not true。它几乎立即开始。做正确事的成本通常是几小时，也许一天，你几乎总是立即 recover that time。也就是说，做对通常花的时间与做错花的时间相同。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”它几乎总是 turns out that it doesn’t save you time at all!它使处理变更更混乱。它使代码审查更长。它在测试中以更混乱的方式失败，需要更长时间调试。它几乎从不节省你实际时间。 偶尔，你路径上有一些“岩石”如此巨大，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了你能发布一个一天的功能，一次。但那是技术债务决策的 tiny, tiny fraction。 这变得更疯狂，因为如果你一切做对_随行_（你总是重构系统，使其看起来像是设计来做 exactly what it does now）那么一切保持相对容易整个时间。但如果你偷工减料，一切变得 compoundingly more difficult，到点你_生成_“岩石”没有人能移动。不像复杂性是某种线性东西，你可以 later go back and invest a linear amount of time to fix。你绝对可以让自己陷入一个如此糟糕的情况，你公司中_nobody_有时间或专业知识修复它。 这一切感觉如此无辜：“让我们 just cut a few corners, it will help us meet this deadline,”（一个通常 imaginary anyway 的截止日期，你可以 slip for a few weeks with no consequences）。“很难弄清楚如何做对，我们可以 punt on it?”然后 bam，很快你发现自己陷入沼泽，一切困难且“we don’t know why!” 我留给你最后一件事：当我直接编码我生活的每一天时，我对此完全 uncompromising。我基本上 incapable of looking at bad code—I must refactor it or I can’t do the work。而且 somehow, I never missed a single deadline in that part of my entire professional career。 阅读更多 9342 分享

Max Kanat-Alexander 5月30日 我估计，我看到的或被告知的每一万条坏建议中，有一条好建议。互联网充满坏建议，因为文明充满坏建议。文明充满坏建议，因为全球教育大多不教人们思考、学习或确定什么是真的。相反，它教人们记忆和重复事实，其中大多数不重要、不真实或无用。 所以总的来说，我们不应该惊讶互联网（尤其是社交媒体）充满不重要、不真实或无用的信息。不是全部那样——我在网上学到了大量非常有用的东西。有大量有价值的内容。我会说，人们对事物的_意见_，无论是在报纸、博客文章、论坛还是什么， rarely had that value, though. 那么要点是什么？嗯，最好有某种方式在开始依赖或向他人重复之前确定某事是否重要或有用的。最简单的工具是说：“它有效吗？”这条数据可靠地帮助你完成某事吗？它100%时间有效，还是更少？ 对于许多帖子，你会发现：这条数据根本不帮助你做任何事。 阅读更多 219 分享

Max Kanat-Alexander 5月29日 你对系统做的任何变更在推出时会收到_somebody_的负面反馈。这发生不是因为每个变更有问题，而是因为用户习惯系统的工作方式，他们不喜欢_它改变了_。他们可能批评新用户界面，或有 some emotional argument about why the new thing “sucks,”但 often they are really just upset that any change happened at all。这不是不寻常的；它是几乎所有人类中存在的一个因素。人们往往有某种 appetite for how much change they are willing to experience in a period of time, and if you go beyond that, they get upset. 重要的是识别 when people’s feedback is simply this “change aversion” vs. real feedback about something valuable。有几种方式判断：

1. 变更厌恶通常持续3到10天。如果你在推出变更后前3到10天内收到用户反馈，且同一反馈不是由大量用户提供，值得考虑用户的响应是否只是变更厌恶。
2. 变更厌恶反馈 often emotional。它可能侮辱性。它可能表达为 just an opinion (“新菜单的颜色丑”) vs a fact (“我测量了，新工具比旧工具慢10倍。”)。 你在管理变更时试图避免的是创建_so_ much change aversion that you cause a revolt。反抗基本上看起来像_so_ many people getting angry that they go to your management and they stop your work。当有疑问时，向更少的人推出更小的变更，以更慢的扩展速率。随着时间的推移，你将学习可以推出多少变更，多快。永远，永远不要做“大爆炸”发布，你所有用户一次体验 massive change。 现在，所有这些 said, never attribute_all_ feedback to “change aversion.” Often people do have feedback that is legitimate。如果许多人提供你相同的 factual feedback, and you look at it and their feedback makes sense and you think fixing it would improve the product, that’s very likely_not_ change aversion。另外，说“这只是变更厌恶”并不意味着你应该完全忽略反馈。你至少应该承认它，让人们知道他们被听到。它_does_ mean you should not argue with the person or try to reason with them about it, because they are having an emotional reaction where you trying to “logic” them out of it won’t help anybody。如果你认为是变更厌恶，你承认他们，他们只是 keep fighting with you, sometimes you should just ignore them and get on with doing your job。如果他们3天后回来带着更合理的论点，那么你知道不只是变更厌恶，而且他们可能那时更有帮助， anyway。 阅读更多 234 分享 加载更多

© 2025 版权所有。由The Fox提供支持。 管理同意联系 关于 书：理解软件 书：代码简洁性 转到顶部