读论文：Programming as Theory Building
编程的本质是构建关于程序如何满足需求的理论，理论丢失是软件退化的根源
- 是什么（What）：
- 编程的本质不是生产代码制品，而是构建一个关于“程序如何满足需求”的理论（theory）。理论存在于程序员和团队的头脑中，代码只是理论的部分外化；理论一旦丢失，软件就会退化。
- 为什么（Why）：
- 需求世界复杂且持续变化，程序必须能适应环境。而理论——程序行为与世界的关系、决策依据、对变化的适应能力——无法被完整记录成文档，只能由人持有。因此软件维护的本质，是维持团队对系统的理论。
- 怎么做（How）：
- 以“理论构建”为视角重新组织工程实践：Clean Code、架构、文档、测试、DDD、设计模式、图表，作用都是帮助团队表达、传递和更新理论；维护时保持团队连续性、重视心智模型交接；用“是否帮助团队共享理论”来评价任何工程实践。
核心问题（问题演化）：
- 编程到底是什么：生产代码制品，还是构建理论？
- 为什么程序即使代码一行未变，也会在维护中退化？
- 理论能否被完整记录下来？若不能，工程实践该如何应对？
- 如何评价一个工程实践是否有价值？
设计思想（核心抽象）：
- theory 的概念与内容：理论是程序员持有的、关于程序如何满足需求、程序行为与世界如何对应的知识，包含决策依据和对变化的适应能力。
- 理论的持有者是团队而非文档：代码、文档只是理论的部分外化，完整理论只能存在于人的头脑中。
- 三种编程观：论文区分 theory-building（理论构建）、rationalist 理性主义（把编程看作产出文档与制品）、craft 技艺观（把编程看作手艺），并论证 theory-building 才是本质。
- 程序退化机制：人员更替 → 理论丢失 → 后续维护只能靠猜 → 程序退化，即使代码本身没有变化。
- 理论的不可表达性：理论无法被穷尽地写成文档；失去理论的人无法靠阅读制品重建它。
工程取舍（为什么这样设计）：
- 为什么不能只靠文档：理论不可穷尽，文档只是部分外化，永远落后于真实的决策与取舍。
- 为什么维护依赖团队连续性：理论由人持有和传递，人员流动是最快的理论流失渠道，交接心智模型比交接代码更重要。
- 为什么实践中会出现形式主义：当实践脱离了“共享理论”的目的，只追求流程、指标、产出物，实践就退化为形式主义。
- 复杂度如何破坏理论的可持有性：复杂度让 theory 无法被完整持有、传递和更新，控制复杂度就是保护理论（呼应 系统理论 的结论）。
启发点（关键洞察）：
- 软件维护的本质是维护团队对系统的理解，而非维护代码。
- 评价工程实践的标尺：是否帮助团队构建、表达、验证、传递系统理论。
- 写代码时考虑理论可传递性：让接手者能重建同样的心智模型。
- 接手代码的首要任务是重建理论，而不是只读代码。
- 好软件不是只有好代码，而是有一套可被团队持续理解和演进的系统理论，参见 系统理论。
评论