- URL: https://www.seangoedecke.com/in-defense-of-not-understanding-your-codebase/
- Added At: 2026-07-11 11:15:47
- Tags: #read
本文批判了“工程师必须彻底理解代码库”的传统观念，指出在大型系统中完全理解不现实，部分理解才是常态。作者反驳了 Peter Naur 的“理论构建”说，强调在不确定性中做出决策的能力比追求虚幻的完全掌握更重要。
本文的作者 Sean Goedecke 针对一个看似理所当然的观点发出了挑战：软件工程师必须彻底理解自己的代码库。他观察到，在小型、团队稳定的项目（如 Redis 或某些独立游戏）中，人们确实倾向于追求完全理解；但在拥有数百万行代码和高人员流动率的大型系统（如 Google 搜索后台）中，完全理解根本不现实。网络上的软件工程讨论被前一种文化主导，而作者要为后一种“部分理解”的正当性辩护。
作者重点批驳了 Peter Naur 的著名论文《编程即理论构建》。Naur 认为，程序员的真正产物不是代码，而是对程序的“理论”（一种直观的、难以文档化的整体理解）。如果团队失去这个理论，那么即便代码还在，也应当弃之不用，让新团队从头重写以建立新的理论。作者指出，这套主张在现代大型系统中完全错误，原因有二：
- 大型系统根本不可能从头重建。几百万行代码中沉淀了无数历史特例和古怪需求，哪怕是熟悉系统的团队也无法整体重写。所有成功的重写，都是把旧系统逐步切分成小块、一块块替换，而这本身就依赖于对旧系统的修改能力。如果你连改动旧系统都做不到，谈何替换？
- “已死”的系统经常被重新激活。在大公司里，一个代码库无人熟知是常有的事，作者本人就多次接手过被遗弃的项目，通过先理清一条端到端流程，再缓慢扩张理解范围，最终能够有效工作。这说明从代码中重新构建理论是完全可能的。
在此基础上，作者进一步指出，在超大型代码库中，所有人的理论都是片面的、甚至部分错误的。因为系统规模超越了任何个人或团队的记忆极限，有效工作的关键不是等待一个全能专家给出答案，而是学会在不确定中做出最佳猜测，并承担后果。
随后，文章将“理论构建”降格为众多工程价值中的一种，需要与其他价值进行权衡。很多人批评大语言模型（LLM）阻碍了程序员构建心理模型，但作者认为这是一种过度简化：LLM 只是影响理论构建的众多因素之一。类似的干扰还包括：
- 允许其他人在你的库中写代码
- 实现法律强制的无障碍或数据保护功能
- 同事离职或转组
- 为安全补丁升级软件版本
- 引入第三方库或依赖
作者承认，几乎所有工程师（尤其是“纯粹”工程师）都更喜欢拥有精确的心智模型，它更有趣、更少压力，更像“真正的工程”。所以许多人会在业余时间投身开源小项目来获得这种体验。然而，在工作中，你拿钱就是要接受雇主的那套工程价值观——就像你个人再重视性能，有时也必须为了赶工期或迁就某些要求而写低效代码一样，为了速度、合规或政治因素而牺牲对代码库的完整理解，也是一种职业常态。
总之，这篇文章是在郑重地告诉读者：在大型系统中，“不完全理解你的代码库”不仅不是罪过，反而是你必须适应的现实。与其追求虚幻的完全掌握，不如锻炼自己在部分理解中做出决策、有效推进工作的能力。