将编程阅读视为构建理论

阅读代码通常被视为理解指令序列的线性过程。然而，一种更有效的方法是将阅读编程的行为视为“构建理论”。开发者不再仅仅是跟随执行流，而是通过阅读代码来构建一个心理模型——即关于系统如何运作、为何存在以及其组件如何交互的“理论”。

这种视角的转变将阅读行为从一种被动活动转变为一种主动调查。当你为了构建理论而阅读代码时，你不仅仅是在问“这一行做了什么？”，而是在问“这个程序的理论是什么？”这种方法允许开发者更有效地导航复杂系统，并为做出连贯而非碎片化的架构决策提供框架。

近视式开发的危险

许多开发者陷入了仅关注单个功能的陷阱。这种近视的视角会导致软件缺乏凝聚力，功能被生硬地拼凑在一起，而不考虑整体架构。正如一位社区成员所指出的，那种“无论其凝聚力如何，只求快速实现”的关注点，往往使开发者无法参与到接口（interfaces）和契约（contracts）等概念中，而这些概念对于长期可维护性至关重要。

当开发者缺乏对程序的连贯理论时，软件就会变成一系列脱节的部分。所谓的“理论”正是连接单个函数与整体系统目标之间的桥梁，确保用于解决问题的机制在整个代码库中保持一致。

构建理论 vs. 设计优化

虽然“构建理论”这个术语可能无法引起每个人的共鸣，但其底层原理与有效软件设计的核心是一致的。有人认为，这个过程与其说是关于“理论”，不如说是关于因子分解（factorization）和表示（representation）的优化。

在这种观点下，编程是心理上探索替代方案以寻找理想因子分解的过程——即如何将问题分解为尽可能简单的接口和最少的活动部件。目标是创建一个实现，使代码读起来就像是对需求的某种高层级描述。在这种语境下，构建理论本质上是完善问题领域的心理模型以最小化复杂性的过程。

LLM 对心理模型的影响

大语言模型（LLMs）的兴起为代码的编写和维护带来了重大转变。虽然 AI 可以快速生成功能性代码，但它往往缺乏对“程序理论”的全面理解。这为人类工程师带来了新的挑战：

• 概念化能力的丧失： 当开发者采取更加“放手”的方式时，他们面临着失去对所监管代码清晰概念化的风险。从“在每个函数中做出 20 个微架构决策”转变为“审查 AI 输出”的过程，可能会导致对系统深度理解的衰退。
• 未知因素的积累： 人们越来越担心，我们正在积累大量我们并不完全理解、甚至从未阅读过的代码。当代码本身是由外部代理编写时，心理模型的重要性变得更加关键。
• 工程师的新角色： 随着 AI 处理编码的战术执行，人类工程师的主要价值转向了上下文的收集与保留——即 AI 难以轻易获取或复制的高层级理论。

结论

无论你称之为“构建理论”、“因子分解优化”还是“心理建模”，可持续软件的核心要求是对系统进行深刻的概念性理解。在一个代码生成正在商品化的时代，通过阅读代码来构建理论的能力仍然是资深工程师最核心的技能。这是确保软件保持连贯、可维护且逻辑严密的唯一途径。