「你到底要对自己的代码库理解到什么程度？」这个问题在软件工程的网上讨论里，答案通常两极分化。
一端是写小代码库、团队稳定的人——Redis、或者像《见证者》（The Witness）这样的游戏——他们会说「当然要完全读懂，否则做不出好东西」。另一端是写大代码库、人员流动高的人——Google 的网页搜索后端、或者 GitHub——他们会说「当然读不完，你只能在自己那块地盘上尽力而为」。
Sean Goedecke 在 2026 年 7 月 11 日的文章《In defense of not understanding your codebase》里，明确站在后者一边。他的判断是：在绝大多数软件工程环境里，「局部理解」是常态、是你唯一能做的状态；在足够大的系统里，它甚至是你能指望的最好结果。
Naur 的「理论构建」走太远了
「你必须读懂代码库」这一派，最经典的表述是 Peter Naur 1985 年的论文《Programming as Theory Building》（编程即理论构建）。Goedecke 喜欢这篇论文，但觉得它推到了错误的方向。
Naur 的核心论点是：程序员写的代码只是副产品；真正在构建的是一个「关于程序的理论」——对系统里发生了什么、为什么发生的直觉。这个理论只能被部分地写进代码或文档。如果代码丢了，熟悉理论的团队能轻松重写；但如果理论丢了（比如团队 100% 换血），光看代码很难重新理解这个程序。
到这里都还好。可 Naur 接着往下说：这个理论不该从代码反推重建。在他看来，与其让新团队啃旧代码，不如把旧程序整个丢掉，让新团队从零重写。「重建一个程序的理论，仅从文档出发，是严格不可能的……因此现有程序文本应被丢弃，新组建的程序员团队应获得机会重新解决问题。」
Goedecke 的反驳很直接：在大型科技公司干过、且真正有效率的工程师都知道，Naur 这句话错得离谱。他给了两个理由。
第一，大软件系统根本不可能从零重写。一个还在被用户使用的足够大的系统，里面塞满了成千上万个「奇怪的边界情况」和怪癖，没法被重新实现。哪怕一支对系统了如指掌的团队也做不到——要同时 juggle 的东西太多了。成功的重写从来都是从旧代码库里切出一小块孤立区域，一次重写一块。换句话说，重写一个系统，本质就是对旧系统做一堆改动；如果你连旧系统都改不动，更不可能用一个新系统替换它。
第二，被抛弃的系统经常被救活。在一个几亿行代码、几千名工程师的科技公司里，一个代码库「一个熟悉它的人都不剩」并不罕见——几个人在错误的时间离职，或者代码库搁置了一年，就够了。Goedecke 不只在别的团队见过，他自己就接手过这种「没人懂」的代码库，花时间摸清它，最后能有效地在上面改东西。方法不神秘：先端到端读懂一条数据流，再慢慢向外扩展，边改边小心验证。
大代码库里，人人都拿着一份错误的理论
Goedecke 下了个狠判断：在足够大的代码库里，每个人都在用一份错误的程序理论干活。现代软件系统的决定性特征就是太大了，大到任何一个人（甚至一整个团队）都不可能装进脑子里——没有人全懂。
要做到有效，你只能学会和一份「部分正确」的理论共处。这正是他一直强调的「表态」和「自信」的来源：如果你对某个东西没把握，不能就坐着等那个「完全懂的人」来给你答案——因为那个人不存在。如果你是个能干的工程师，那个人就是你。你得咬咬牙，做最靠谱的猜测，然后去承担后果。
他也替 Naur 找台阶：1985 年一个「大程序」的平均体量，可能比今天小好几个数量级。Naur 举的「大程序」例子，一个是 20 万行的工业监控程序，一个是编译器；而 GCC 在 1987 年约 10 万行，到 2015 年已经超过 1400 万行。重写一二十万行、还能复用旧测试，他信；重写一两百万行，不信。
LLM 不是理论构建的天敌
文章最有意思的一段，是把这场讨论拉到当下的 AI 语境。LLM 常被批评「阻碍了正常的理论构建过程」，Goedecke 认为这过于简单。和很多软件工具一样，LLM 是双刃剑：它让你更难构建一份细致的心智模型，但也让你能更快地搭起一份局部理论，并更有效地利用这份局部理论去干活。这是个复杂的权衡，他自己也还在想。
把 LLM 先放一边，他确信一件事：说「任何干扰你构建代码理论的东西都是坏的」，这话本身就蠢。下面这些同样会干扰你维护理论：
- 允许别人在你的代码库里写代码
- 被迫实现法律要求的无障碍、数据保护功能
- 同事辞职或转岗
- 为了安全补丁被迫升级软件版本
- 引入第三方库或依赖
和软件里大多数东西一样，「维护代码库的理论」只是众多价值中的一个。有时候它最重要，你为它牺牲别的；有时候你为了速度、法律合规或政治原因，拿它去换别的。
几乎所有工程师——尤其是「纯」工程师——都偏好维护一份准确的心智模型。这更有趣、压力更小、也更像「真正的工程」。这也是为什么很多工程师业余去搞开源项目：在小的个人代码库上，他们才能维持一份准确的 Naur 式理论。Goedecke 不觉得这有错。
但在工作中你是拿钱办事的。换句话说，公司付你钱，是为了让你采用他们那套工程价值观。这点应该很好懂：不管你多在意性能，工作上有时也得写慢代码（比如为了按时交付，或者迁就某个别扭的需求）。维护代码库的理论，是同一类东西。
他此前在《Pure and impure software engineering》里专门写过：软件行业里很多反复发生的争吵，根源就是「纯」的「全理解」文化，撞上了「不纯」的「局部理解」文化。
这件事为什么现在被反复提起
这篇文章在 Lobsters 上挂着 practices 和 vibecoding 两个标签，10 条评论。它踩中的正是 2026 年最敏感的那根神经：当 AI 编码助手能帮你「局部理解并快速改动」时，工程师对代码的全盘掌握到底是刚需还是执念。
Goedecke 的立场很直接：读不完是正常的，别因为读不完就觉得自己不专业。这对大厂工程师是个实在的安慰，对把「读懂每一行」当信仰的人则是个提醒：Naur 写那篇论文时，GCC 才 10 万行。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
参考链接：
- Sean Goedecke 原文：https://www.seangoedecke.com/in-defense-of-not-understanding-your-codebase/
- Lobsters 讨论：https://lobste.rs/s/9xq2mz/in_defense_of_not_understanding_your_codebase
- Peter Naur《Programming as Theory Building》(1985)：https://pages.cs.wisc.edu/~remzi/Naur.pdf