在头脑中保持一个程序
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 阅读了本文的初稿。