软件即知识:代码简洁性的哲学与技术思考

本文探讨软件本质即知识的哲学观点,分析代码简洁性与知识管理的关系,讨论技术债务的真实成本,并涉及AI开发中验证机制的重要性,为开发者提供深层技术思考。

软件即知识 » 代码简洁性

管理同意

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

功能性

始终活跃
技术存储或访问对于实现用户明确请求的特定服务的合法目的,或仅为了通过电子通信网络进行通信传输的唯一目的,是绝对必要的。

偏好

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

统计

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

营销

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

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

代码简洁性

软件即知识

2012年5月10日 by Max Kanat-Alexander

我不常深入探讨《代码简洁性》的哲学基础,但我越来越意识到这些文字背后有一些有价值的哲学原则值得分享。此外,其中一些哲学观点直到我长时间投入工作、在许多情境中应用并与多人讨论后才完全形成。这一个——我逐渐发展的关于如何在脑海中思考和操作软件的理论——已经在我脑海中酝酿了相当长一段时间。现在是时候至少在博客文章中将其部分内容“写在纸上”了。所以,请看:

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

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

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

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

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

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

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

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

-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):

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

输入您的电子邮件… 订阅

Max Kanat-Alexander 7月28日 非常兴奋地宣布我将在2025年开发者生产力工程峰会上发表主题演讲之一。我将谈论什么造就了伟大的开发者体验。我自1995年以来一直在技术领域工作,自2004年以来几乎全职从事开发者体验。关于如何使开发者体验变得伟大,有一些基本的、普遍的真理,我将尽力在有限的时间内涵盖尽可能多的内容。希望能见到你。:) 阅读更多 131 11 分享

Max Kanat-Alexander 6月27日 我目前认为,AI代理能够成功生成的输出数量和质量取决于:

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

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

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

加载更多

© 2025 版权所有。由The Fox提供支持。

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

转到顶部

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计