在脑海中构建程序
2007年8月
一个优秀的程序员在专注于自己的代码时，能够像数学家处理正在研究的问题一样，将整个程序保持在脑海中。数学家并不像学校里教的那样，通过纸笔计算来解答问题。他们更多是在脑海中思考：他们试图充分理解问题空间，就像你可以在记忆中漫步于你长大的房子一样。编程在最佳状态下也是如此。你将整个程序保持在脑海中，可以随心所欲地操作它。
这在项目开始时特别有价值，因为最初最重要的是能够改变你正在做的事情。不仅仅是换一种方式解决问题，而是改变你正在解决的问题。
你的代码就是你对你正在探索的问题的理解。因此，只有当你将代码保持在脑海中时，你才能真正理解这个问题。
将程序装入脑海并不容易。如果你离开一个项目几个月，当你重新回到项目时，可能需要几天时间才能真正理解它。即使你正在积极开发一个程序，每天开始工作时也需要半小时才能将其装入脑海。这还是最好的情况。在典型办公条件下工作的普通程序员从未进入这种状态。或者更戏剧性地说，在典型办公条件下工作的普通程序员从未真正理解他们正在解决的问题。
即使是最好的程序员也并不总是能将他们正在处理的整个程序都装入脑海。但有一些事情可以帮助你：
避免分心。分心对许多类型的工作都不利，但对编程尤其不利，因为程序员往往在能处理的细节极限上工作。
分心的危险不在于它持续多久，而在于它会在多大程度上扰乱你的思维。程序员可以离开办公室去买个三明治，而不会丢失脑海中的代码。但错误类型的干扰可能在30秒内就抹去你的思维。
奇怪的是，预定的分心可能比未预定的更糟糕。如果你知道一小时后有个会议，你甚至不会开始处理困难的事情。
长时间工作。由于每次开始处理程序时都有固定成本，所以用几个长时间段工作比用多个短时间段更有效率。当然，当你因为疲劳而变得迟钝时，就到了一个临界点。这个临界点因人而异。我听说过有人能连续编程36小时，但我最多只能坚持18小时，而且我最适合的工作时间不超过12小时。
最佳状态并不是你身体能承受的极限。分解项目既有成本也有优势。有时当你休息后重新回到问题时，你会发现你的潜意识已经为你准备好了答案。
使用简洁的语言。更强大的编程语言使程序更短。而且程序员似乎至少部分地用他们正在使用的语言来思考程序。语言越简洁，程序越短，就越容易装入和保持在脑海中。
你可以通过使用一种称为自底向上编程的风格来放大强大语言的效果，在这种风格中，你用多层编写程序，较低层为较高层提供编程语言。如果你做得对，你只需要在脑海中保持最顶层。
不断重写你的程序。重写程序通常会产生更清晰的设计。但即使没有这个好处，重写也有优势：你必须完全理解一个程序才能重写它，所以没有比这更好的方法来将程序装入脑海。
编写可重读的代码。所有程序员都知道编写可读代码是好的。但你自己是最重要的读者。尤其是在开始时；原型就是与自己的对话。当你为自己写作时，你有不同的优先级。如果你是为他人写作，你可能不想让代码过于密集。程序的某些部分如果像入门教科书那样展开，可能最容易阅读。而如果你编写代码是为了让它容易重新装入脑海，那么追求简洁可能是最好的。
在小团队中工作。当你在脑海中操作程序时，你的视野往往止于你拥有的代码边缘。其他部分你理解得不够好，更重要的是，不能随意修改。因此，程序员数量越少，项目就越能完全改变。如果只有一个程序员，就像开始时经常那样，你可以进行全面的重新设计。
不要让多个人编辑同一段代码。你永远无法像理解自己的代码那样理解他人的代码。无论你多么仔细地阅读过，你只是读过它，而不是写过它。所以如果一段代码由多个作者编写，他们中没有一个人能像单个作者那样理解它。
当然，你也不能安全地重新设计其他人正在工作的内容。这不仅仅是因为你需要获得许可。你甚至不会让自己想到这样的事情。重新设计由多人编写的代码就像修改法律；重新设计你独自控制的代码就像看到模糊图像的另一层含义。
如果你想让几个人一起处理一个项目，将其分成组件并分配给每个人。
从小开始。随着你对程序越来越熟悉，它就越容易保持在脑海中。一旦你确信已经完全探索了某些部分，你就可以开始将它们视为黑盒。但当你第一次开始处理一个项目时，你被迫看到所有内容。如果你一开始就处理太大的问题，你可能永远无法完全掌握它。所以如果你需要编写一个大型、复杂的程序，最好的开始方式可能不是为它写一个规范，而是写一个解决问题子集的原型。无论规划有什么优势，它们往往被能够将程序保持在脑海中的优势所超越。
值得注意的是，程序员经常能意外地满足这八点。有人有了一个新项目的想法，但因为这不是公司支持的，他必须在业余时间做——结果因为没有分心而更有效率。由于对新项目的热情，他连续工作很多小时。因为最初只是一个实验，他没有使用"生产"语言，而是使用了一个"脚本"语言——实际上这种语言更强大。他完全重写了程序几次；这对官方项目来说是不合理的，但这是一个充满爱的劳动，他希望它完美。而且因为除了他自己没有人会看到它，他省略了任何注释，只保留给自己看的笔记。他被迫在小团队中工作，因为他要么还没有告诉其他人这个想法，要么这个想法看起来太没有前途，不允许其他人参与。即使有一个团队，他们也不能让多个人编辑同一段代码，因为它变化太快，不可能这样做。而且项目从小开始，因为想法最初很小；他只是想尝试一些很酷的黑客技巧。
更令人惊讶的是，有多少公司的项目成功地做到了这八点全错。事实上，如果你看看大多数组织中软件是如何编写的，几乎就像他们故意要做得错一样。从某种意义上说，他们确实如此。自从有组织这种东西以来，它的一个定义性特征就是将个人视为可互换的部件。这对更可并行化的任务很有效，比如打仗。在历史上大多数时候，一支训练有素的专业士兵军队可以击败一支由个人勇士组成的军队，无论这些勇士多么勇敢。但产生想法并不是很可并行化的。而程序就是：想法。
组织不仅不喜欢依赖个人天才的想法，这几乎是一个同义反复。这是组织定义的一部分。至少是我们当前对组织的概念。
也许我们可以定义一种新的组织，它能够结合个人的努力，而不要求他们可互换。可以说市场就是这样一种组织形式，尽管更准确地说，市场可能是一个退化的情况——当组织不可能时你默认得到的东西。
可能我们能做到的最好的就是某种黑客式的解决方案，比如让组织的编程部分以不同于其他部分的方式工作。也许最优解决方案是大公司甚至不要试图在内部开发想法，而是直接购买它们。但无论最终解决方案是什么，第一步是要意识到存在问题。“软件公司"这个词本身就存在矛盾。这两个词在相反的方向拉扯。任何在大组织中的优秀程序员都会与组织产生冲突，因为组织设计的目的就是防止程序员所追求的东西。
优秀的程序员仍然设法完成了很多工作。但这往往需要几乎是对雇佣他们的组织的反叛。如果更多人理解程序员的行为是由他们工作的需求驱动的，这可能会有所帮助。他们之所以在长时间的工作中忽略所有其他义务，直接投入编程而不是先写规范，重写已经工作的代码，并不是因为他们不负责任。他们之所以更喜欢独自工作，或者对探头进来打招呼的人咆哮，并不是因为他们不友好。这些看似随机的烦人习惯有一个简单的解释：在脑海中构建程序的力量。
无论理解这一点是否能帮助大型组织，它肯定能帮助他们的竞争对手。大公司最薄弱的一点是他们不让个别程序员做出伟大的工作。所以如果你是一个小创业公司，这就是攻击他们的地方。承担那些必须在一个大脑中解决的问题。
感谢 Sam Altman、David Greenspan、Aaron Iba、Jessica Livingston、Robert Morris、Peter Norvig、Lisa Randall、Emmett Shear、Sergei Tsarev 和 Stephen Wolfram 阅读本文草稿。
英文版：paulgraham.com/head.html｜中文版：HiJiangChuan.com/paulgraham/080-holding-a-program-in-ones-head
更新记录：
- 2025-04-28 HiJiangChuan 初稿翻译，术语待验证；
- 2025-04-28 更新部分细节；