以理论构建的视角阅读编程

# 你应该阅读《编程即理论构建》 来源：https://codeutopia.net/blog/2026/05/09/you-should-read-programming-as-theory-building/ 当我读完 Peter Naur 的《编程即理论构建》（Programming as Theory Building）后，我的第一个念头是：“为什么没人早点告诉我该读这篇？” 我反复读了很多遍，因为我试图整理思绪，弄清楚它为何如此有说服力。 你是否曾遇到过这种情况：你试图解释某事或表达某个观点，在脑海中寻找合适的词汇或术语，但无论如何也找不到？我认为，在编写优质代码和打造可维护软件方面，Naur 所说的“理论”正是那个缺失的术语。关于这些主题，我曾有许多想法和见解，但它们都是零散的概念，即便将它们放在一起，也无法真正回答“为什么编写优质软件如此困难？”这个问题。而正如 Naur 所言，将编程视为“理论构建”，正是那块缺失的拼图，它将所有碎片串联起来，并给出了答案。 简而言之，《编程即理论构建》提出：程序代码、文档及其他产物，相对于编程的本质而言都是次要的。编程的真正核心在于：构建对程序、其需求以及它们与周围环境之间关系的理解，也就是建立一个心理模型（mental model）。也就是说，作为程序员，你的首要目标是学习、理解、保持、改进并分享这一关于程序的“理论”。 理论的所有方面都会影响程序代码（我作弊了一下，在这幅图中用了文字工具） 当你想到“好代码”或“可维护的代码”时，脑海中浮现的是什么？大概是一些让代码更易于理解的事物，比如遵循良好的规范、编写“整洁”代码、拥有良好的架构等等。你可能还会想到文档和图表。也许还有自动化测试。 仔细想想，所有与编写可维护代码相关的活动的目标，实际上都是为了传达代码的设计意图。你编写整洁的代码，是因为它易于理解其功能；你设计代码架构，是为了让人容易理解其结构及其目的；你添加文档以帮助解释代码的作用，绘制图表也是为了类似的目的。但根据我的经验，开发者往往将这些不同的方面视为独立的活动——例如，编写测试是一项有其自身目标的活动，编写文档是另一项活动，等等。 如果按照 Naur 的建议，将编程视为理论构建，你就会看到这些活动是一个更大整体的一部分：即传达程序的“理论”。当它们被视为更大整体的一部分时，你就可以利用这些独立活动更好地实现共同目标。而传达程序的“理论”至关重要：如果你在不理解该理论的情况下尝试修改程序，你将无法以一种非“ hacky”（牵强/拙劣）的方式来完成修改。同样，如果你需要评估对代码进行某些更改（如添加新功能）的可行性，若没有对理论的理解，你也无法做到这一点。 从这个意义上说，编程就是理论构建。 如果你以这种方式思考，突然间许多事物都联系在了一起。例如，设计模式和领域驱动设计（Domain-Driven Design）有什么共同点？它们帮助你传达代码中使用的想法和心理模型——也就是说，它们有助于传达程序的“理论”。同样，其他人提出的概念如“智力控制”（Intellectual Control）（https://www.georgefairbanks.com/ieee-software-v36-n1-jan-2019-intellectual-control）——拥有程序的心理模型，使你能够确认其正确工作，并推理其中的变更等等——也可以被视为一种“理论构建”的形式。 希望我至少传达了一些阅读 Peter Naur 这篇文章的价值所在。其中还有更多内容，因此我强烈建议阅读原始的《编程即理论构建》文本。文章不算太长，你在 Google 上很容易就能找到——我本可以附上链接，但版权方面有些灰色地带，而且我不得不通过别人的网站进行深度链接。如果你已经读过，我非常想听听你的看法。