在脑海中保持一个程序
Original2007年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 阅读草稿。