代码即知识

作者：Max Kanat-Alexander
发布日期：2012年5月10日

我通常不会深入探讨“代码简洁性”背后的哲学基础，但越来越意识到，这些文字背后的一些哲学原则值得分享。其中一些理念直到我长期投入工作、在多场景应用并与许多人讨论后才逐渐成形。这一个——关于如何在心智中将软件视为知识并与之协作的理论——已经在我脑海中酝酿了相当长的时间。现在是时候至少将其部分内容通过博客文章“写在纸上”了。那么，开始吧：

从根本上说，软件是由知识构成的实体。它遵循知识的所有规则和定律。在几乎所有给定情境中，它的行为方式与知识完全相同，只不过它以具体形式存在。例如，当软件复杂时，它容易被误用；当软件出错（即存在漏洞）时，它往往造成损害或问题；当人们不理解某些代码时，他们容易错误地修改它。这些描述既适用于知识，也适用于软件。错误的数据导致人们行为失常；错误的代码导致计算机行为失常。我并不是在比较计算机和人——我是在说软件和知识可以比较。

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

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

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

然而，在更多情况下，我们必须依赖二手数据。如果一个人想在生活中做好工作，有很多需要知道的东西——一个人根本无法独自获取这么多信息。这就是他人帮助的作用：他们知道的数据、他们学到的教训以及可以教给我们的东西。

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

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

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

• Max

评论

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
是的，当然，哲学知识在实际编码之前很重要。

回复

Software as Knowledge – 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等客观验证的单独部分。
   注意，输入的质量也很重要且在我们控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎所有帮助人类编写代码的东西也帮助代理。
   阅读更多
   2310 分享

Max Kanat-Alexander
6月4日
技术债务有价值的想法大多是个神话。当你做出糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。这是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但这根本不正确。它几乎立即开始。做正确事的成本通常是几小时，也许一天，而你几乎总是立即收回那个时间。也就是说，做对通常花费与做错相同的时间。“等等，什么？怎么可能？我们偷工减料是为了节省时间！”结果几乎总是它根本不会节省你的时间！它使处理变更更加混乱。它使代码审查时间更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从未节省你的实际时间。
偶尔，你的路径上有些“岩石”如此巨大，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了你能一次交付一个一天的功能。但那是技术债务决策中极小极小的一部分。
这变得更疯狂，因为如果你在过程中做对一切（你总是重构系统，使其看起来像是设计来做现在 exactly 做的事情），那么一切始终保持相对容易。但如果你偷工减料，一切变得复合性地更困难，以至于你生成没人能移动的“岩石”。复杂性不是某种线性的东西，你可以后来投入线性时间修复。你绝对可以让自己陷入一个如此糟糕的境地，以至于你公司中没有人有时间或专业知识修复它。
这一切感觉如此无辜：“让我们偷工减料吧，它会帮助我们满足这个截止日期”（一个通常是想像的截止日期，你可以推迟几周而没有任何后果）。“很难弄清楚如何做对，我们可以推迟吗？”然后砰，很快你发现自己陷入沼泽，一切都很困难，“我们不知道为什么！”
我最后留给你一件事：当我每天直接编码时，我在这方面完全 uncompromising。我基本上无法看坏代码——我必须重构它，否则我无法工作。不知何故，在我整个职业生涯的那部分，我从未错过一个截止日期。
阅读更多
12940 分享

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

Max Kanat-Alexander
5月29日
你对系统做的任何更改在推出时都会收到某个人的负面反馈。这不是因为每个更改都有问题，而是因为用户习惯了系统的工作方式，他们不喜欢它改变了。他们可能批评新用户界面，或有 some emotional argument about why the new thing “sucks,” but 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.
重要的是 recognize when people’s feedback is simply this “change aversion” vs. real feedback about something valuable. 有几种方式可以判断：

1. 变更厌恶通常持续3到10天。如果你在推出更改后的前3到10天内收到用户的反馈，并且同一反馈不是由大量用户提供的，值得考虑用户的响应是否只是变更厌恶。
2. 变更厌恶反馈通常是情绪化的。它可能是侮辱性的。它可能 expressed as just an opinion (“新菜单的颜色很丑”) vs a fact (“我测量了，新工具比旧工具慢10倍。”).
   管理变更时，你试图避免的是创建如此多的变更厌恶以至于引起反抗。反抗基本上看起来像如此多的人生气，他们去找你的管理层并停止你的工作。如有疑问，向更少的人推出更小的更改，以更慢的扩展速度。随着时间的推移，你将学会可以推出多少变更，多快。永远不要做“大爆炸”发布，让你所有用户一次体验 massive change。
   现在，所有这些 said, never attribute all feedback to “change aversion.” 通常人们确实有合法的反馈。如果许多人提供你相同的事实反馈，你查看它，他们的反馈有道理，你认为修复它会改进产品，那很可能不是变更厌恶。另外，说“这只是变更厌恶”并不意味着你应该完全忽略反馈。你至少应该承认它，让人们知道他们被听到了。它确实意味着你不应该与那个人争论或试图与他们推理，因为他们正在情绪化反应，你试图用“逻辑”说服他们不会帮助任何人。如果你认为是变更厌恶，你承认他们，他们只是继续与你斗争，有时你应该忽略他们并继续做你的工作。如果他们3天后带着更合理的论证回来，那么你知道不只是变更厌恶，而且他们可能那时更有帮助。
   阅读更多
   274 分享
   加载更多

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