为“不理解你的代码库”辩护
背景与摘要
本文挑战了软件工程界中一个根深蒂固的观念——工程师必须对其代码库有全面且彻底的理解（即彼得·诺尔的“编程即理论构建”理论）。作者认为，在现代大型系统中，“部分理解”不仅是常态，更是一项必要的职业技能。尽管在小型项目中维持完美的心智模型是理想的，但在大型组织中，工程师必须学会在信息不全的情况下做出合理推断，在无法完全掌握系统的情况下有效应对复杂性。
Summary
在软件行业，人们普遍认为（往往根源于彼得·诺尔的《编程即理论构建》）——工程师必须对他们的代码库有完整、全面的理解才能发挥作用。本文挑战了这一观念，认为对于大型现代系统而言，“部分理解”不仅是一个现实，更是一项必要的专业技能。虽然维持一个完美的心智模型对于小型项目来说是理想的，但大型组织中的工程师必须学会在信息不完整的情况下操作，做出有根据的猜测并在没有完全掌握系统的情况下驾驭复杂性。
In the software industry, there is a pervasive belief—often rooted in Peter Naur’s Programming as Theory Building—that engineers must possess a complete, holistic understanding of their codebase to be effective. This article challenges that notion, arguing that for large-scale, modern systems, "partial understanding" is not just a reality, but a necessary professional skill. While maintaining a perfect mental model is ideal for small projects, engineers in large organizations must learn to operate with incomplete information, making educated guesses and navigating complexity without the luxury of total system mastery.
Against “Programming as Theory Building”
彼得·诺尔那篇颇具影响力的论文认为，编程的主要产物是开发者对系统的“理论”——一种无法完全被文档捕获的直观理解。诺尔有一句名言：如果一个团队失去了这个理论，唯一可行的途径就是废弃代码并从头开始。
Peter Naur’s influential paper argues that the primary product of programming is the developer's "theory" of the system—an intuitive understanding that cannot be fully captured by documentation. Naur famously suggests that if a team loses this theory, the only viable path is to scrap the code and start over.
我认为诺尔错了，主要有两个原因：
I contend that Naur is mistaken for two primary reasons:
- 大型系统无法从头重建： 现代软件充满了“奇怪的情况”和历史包袱，这些在推倒重来的重写中是不可能复制的。这些系统的成功演进需要增量式的、孤立的修改，而不是全面替换。
- Large systems cannot be rebuilt from scratch: Modern software is riddled with "weird cases" and historical quirks that are impossible to replicate in a clean-slate rewrite. Successful evolution of these systems requires incremental, isolated changes, not total replacement.
- 被遗弃的系统经常被复活： 在大型科技公司中，代码库失去其原作者是很常见的。工程师经常接手“孤儿”代码，通过一次探索一个流程来构建系统的功能理论。
- Abandoned systems are routinely revived: It is common in large tech companies for codebases to lose their original authors. Engineers frequently take ownership of "orphaned" code, building a functional theory of the system by exploring one flow at a time.
在现代的庞大代码库中，每个人都在带着一个不正确或不完整的理论进行操作。 要成为一名有效的工程师，你必须克服必须了解一切带来的瘫痪感。你必须愿意表明立场，做出有根据的猜测，并承担相应的后果。
In modern, massive codebases, everyone operates with an incorrect or incomplete theory. To be an effective engineer, you must move past the paralysis of needing to know everything. You must be willing to take a position, make an educated guess, and manage the consequences.
Theory Building is One Tradeoff Among Many
维持代码库的心智模型是一项有价值的追求，但这只是众多价值中的一种。它通常会与以下方面发生冲突：
Maintaining a mental model of a codebase is a valuable pursuit, but it is only one value among many. It often competes with:
- 协作开发（多个人接触同一段代码）。
- Collaborative development (multiple people touching the same code).
- 合规性和法律要求（无障碍、数据保护）。
- Compliance and legal requirements (accessibility, data protection).
- 组织动荡（同事离职或转岗）。
- Organizational churn (colleagues leaving or moving teams).
- 安全和维护（升级依赖项）。
- Security and maintenance (upgrading dependencies).
许多工程师更喜欢参与小型单人项目的“纯粹”体验，在这些项目中，他们可以维持一个完美的心智模型。然而，在职业环境中，你拿薪水是为了接受组织的价值观。有时候，这意味着牺牲完全理解的舒适感以满足截止日期，适应业务需求，或应对政治限制。
Many engineers prefer the "pure" experience of working on small, solo projects where they can maintain a perfect mental model. However, in a professional environment, you are paid to adopt the organization's values. Sometimes, that means sacrificing the comfort of total understanding to meet deadlines, accommodate business requirements, or navigate political constraints.
Conclusion
业界常常过度强调“完全理解”的视角，因为这是开源和小型团队开发的标准。然而，大规模工程的现实由局部推理能力和在你无法（也不可能）完全理解的系统中有效工作的能力所定义。接受这种限制并不是工程上的失败；这是在现代软件领域生存的必要条件。
The industry often over-represents the "total understanding" perspective because it is the standard for open-source and small-team development. However, the reality of large-scale engineering is defined by the ability to reason locally and work effectively within a system you do not—and cannot—fully comprehend. Accepting this limitation is not a failure of engineering; it is a requirement for survival in the modern software landscape.
注：本文灵感来源于对软件工程本质、LLMs在代码理解中的作用，以及“纯粹”与“不纯粹”工程环境之间的文化差异的持续讨论。
Note: This article was inspired by ongoing discussions regarding the nature of software engineering, the role of LLMs in code comprehension, and the cultural divide between "pure" and "impure" engineering environments.