从《Programming as theory building》学到了什么?

http://pages.cs.wisc.edu/~remzi/Naur.pdf 图灵奖得主 Peter Naur 写于 1985 年

TLDR，给你摘要关键的段落

program 的生与死，决定于当初原创者还有多少在积极维护它。程序员不是可替换的螺丝钉

The state of program (life, death, revival) = programmers having its theory reamin in charge of it. During the program life a programmer team possessing its theory remains in active control over all modifications. The death of a program happens when the programmer team possessing its theory is dissolved.

文档用处不大

A very important consequence of the Theory Building View is that program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible.

Theory of program 就是程序员识别 similarity 的能力

What is needed in a modification, first of all, is a confrontation of the existing solution with the demands called for by the desired modification. In this confrontation the degree and kind of similarity between the capabilities of the existing solution and the new demands has to be determined. This need for a determination of similarity brings out the merit of the Theory Building View.

我们可以看几张小猫咪的照片，然后就可以识别更多的照片是猫咪。但是你无法把什么是一个猫咪的规则写成文档。你有一个识别 similarity 的潜在 theory 在你的脑子里，无法用语言表达出来，只能体现在你的行为里。

这就是 Peter Naur 核心的观点，Programming as theory building。

以下是我的读后感部分

分封与田产

Theory Building View 的重要推论是 Program 和其核心团队是绑定的，程序员不可以变成替换的螺丝钉。Program 以及其上所运行的业务，产生的收入，就是团队的收益。类似于田产分封给了某个诸侯。这种分封制的合理性就来自于 Program 的维护状态，与其核心团队还有多少人在管事有关。

积极的方面在于，程序员可以更有 ownership，更投入于自己负责的模块。坏的方面在于鼓励了占山为王，故意制造门槛的行为。例如一些情况下，某些人会用特定的语言来重写系统，主要的目的在于和其他团队制造隔阂，不容易被其他团队给吞并掉。或者一些极端的个人会故意把代码写成只有自己能维护的状态，制造职业安全感。

微服务是事实上的分封制。拥抱业务，就是拥抱所被分封的田产。

可调试的“可工作的软件”是更好的文档

文档显然是没啥用的，因为字数不够。信息经过高度压缩了之后，才落成了文档。如果文档包含了一切细节，那就是源代码本身了。所以文档 by definition 就是有损的压缩。

源代码处于不能运行的状态，并不能提供所有的信息。如果源代码可以变成“可工作的软件”，可以被方便地调试。通过使用，通过调试，可以获得快速地获得准确的知识。与其费心费力地写文档，不如在“可工作的软件”本身内置良好的可调试性，把“文档”内置到日志里，内置到调试工具里。这个就像是你读英语课本，一下子升级为 51talk 真人一对一外教。哪个学习效率更高，不言而喻。

设计原则的外化表达

Peter Naur 认为，程序员能够根据自己的人脑中的模型，去识别 similarity，做出设计决策。这个判断没有问题，只要人类还没有灭绝，软件设计最重要的因素肯定是人为决策（如果机器可以开始写代码了，我预测人类也不久就会灭绝）。但是这并不代表，我们不能把一些设计原则固化下来，变成编译器可以检查的架构 invariants。

很大程度上，变量的类型，包的dependency，这些就是“原作者”外化表达的设计原则。当它被“修改者”破坏的时候，编译器就会报错。这个时候就促成了“修改者”去询问“原作者”这么改行不行。如果没有外化表达的设计假设，要发现这些 violation 就非常困难了。

所以，如果可能，不要满足于把 Theory 仅藏在你的脑袋里，把设计决策变成无法言传的神秘现象。应该尽可能地把“你为什么这么做”给表达出来。虽然不可能完全外化表达，但是如果可能让编译器帮我们做一些检查，还是应该积极地去做。在编译器可以检查的东西里，最重要的就是“依赖关系”检查。