把一个程序装在脑子里
原文：Holding a Program in One’s Head
作者：Paul Graham 发表：2007-08
译者：Claude（baoyu-translate）
2007 年 8 月
一个好的程序员在专注地写自己的代码时——他能把这个程序装在脑子里——就像数学家把一个正在做的问题装在脑子里那样。数学家解题不是像小学课堂上教的那样在纸上一步步算出来——他们更多的是在脑子里做事——他们试图把问题空间理解到——他们能像在自己童年成长的房子的记忆里走来走去那样在这个空间里走来走去。编程在最好的状态下也是同一回事——你把整个程序装在脑子里——你能任意地操控它。
这一点在项目早期尤其有价值——因为最初最重要的事情是——能够改变你正在做什么——不仅是用不同的方式解决问题，而是改变你正在解决的问题。
你的代码就是你对’你正在探索的问题’的理解。所以——只有当你把代码装进脑子里时，你才真正理解了那个问题。
把一个程序装进脑子里是不容易的。如果你离开一个项目几个月——回头时可能要花好几天才能重新真正理解它。即使你正在主动地做一个程序——每天开始工作时也可能要花半个小时把它装载进你的脑子。而且这是最好情况。在典型办公室条件下工作的普通程序员从来进不了这种状态。或者更戏剧性地说——在典型办公室条件下工作的普通程序员从来不真正理解他们在解决的问题。
即使是最好的程序员，也并非总能把整个正在做的程序装进脑子。但有些事可以帮上忙：
-
避开分心源。分心对很多类型的工作都不好——但对编程尤其差——因为程序员往往是在自己能处理的细节上限处工作。
分心的危险并不取决于它有多长——而取决于它把你的脑子搅乱多少。一位程序员可以离开办公室出去买个三明治而不丢掉脑子里的代码——但错的那种打断可以在 30 秒里把你的脑子清空。
奇妙的是——’计划好的分心’可能比’计划之外的分心’更糟。如果你知道自己 1 小时后有个会——你甚至不会去开始做难的事。
-
长时段工作。既然每次开始做一个程序都有固定的“上手成本“——做几个长时段比做许多短时段更有效。当然——你最终会到一个’累到变笨’的点——这件事每个人不同。我听说过有人连续 hacking 36 小时——但我自己最多也就 18 小时——而我做得最好的状态是不超过 12 小时一段。
最优值不是你身体能撑到的极限。把一个项目分段也有它的好处——有时你休息后回到一个问题——会发现你的潜意识已经替你留好了答案。
-
用更简洁的语言。更强大的编程语言让程序更短。而程序员对程序的思考至少在某种程度上是用他们正在写的那门语言进行的。语言越简洁——程序就越短——把它装进脑子也越容易。
你可以通过一种叫做’自底向上编程’的风格放大一门强大语言的效果——你把程序写成多层结构——下层充当上层的编程语言。如果你做得对——你只需要把最上面那一层装在脑子里就够了。
-
不停重写你的程序。重写一个程序往往会得到更干净的设计——但即使不能——它也仍然有好处：你必须完全理解一个程序才能重写它——所以再没有比重写更好的’把它装进脑子’的方式。
-
写“可重读“的代码。所有程序员都知道’写易读的代码很好’——但你自己才是最重要的读者——尤其在早期——一份原型就是你和自己的对话。当你写给自己看时，你的优先级是不同的——给别人看的代码——你也许不希望它太密——程序的某些部分如果像入门教材那样铺开来读会更方便。而当你写代码是为了让它能容易地被’重新装回脑子’——简洁也许就是最好的选择。
-
小组工作。当你在脑子里操控一个程序时——你的视线倾向于停在’你拥有的代码’的边缘——其他部分你既不那么懂，更重要的是——你也不能对它们随便动手。所以——程序员越少，一个项目能突变得越彻底。如果只有一个程序员——这经常是项目早期的情况——你可以做包罗万象的重新设计。
-
别让多人编辑同一段代码。你永远不会像理解自己的代码那样理解别人的代码——不管你读得多仔细——你只是读了它，而不是写了它。所以——如果一段代码是被多人写的——他们里没有谁会像单一作者那样理解它。
而你当然不能安全地重新设计’别人正在做’的东西——这不仅是因为你需要征求许可——你甚至连’想’这件事都不会让自己想。多作者代码的重新设计就像改一部法律；单作者代码的重新设计——则像看出一张多义图（像那种“老妇/少女“两可图）的另一种解读。
如果你想让几个人一起做一个项目——把它拆成几个组件——每个组件给一个人。
-
从小开始。随着你对一个程序越来越熟，把它装进脑子就越容易——等你确认自己已经完全摸透某些部分后——你可以开始把它们当黑盒对待。但当你刚开始做一个项目时——你被迫看到一切。如果你一开始就上一个太大的问题——你可能永远没法把它整个包住。所以——如果你需要写一个又大又复杂的程序——开始的最佳方式可能不是’写一份规格说明’——而是’写一个解决子集问题的原型’。’计划’的好处常常会被’能把程序装进脑子’的好处盖过。
让人吃惊的是——程序员经常无意中把这 8 条都击中了。某人有一个新项目的点子——但因为这件事没有被官方批准——他得在业余时间做。而业余时间反而更高产——因为没有分心源。被对新项目的兴奋所驱动——他一连做好几小时。因为这本就是个实验——他不用’生产语言’——他用一种’仅仅是脚本语言’的东西——而这其实是更强大得多的语言。他把程序整个重写了好几次——这件事在一个官方项目里没法被合理化——但这是一项情书般的爱劳动——他想让它完美。而且因为没人会看见它（除了他自己）——他不写注释（除了那种’写给自己看’的便条式注释）。他被迫小组工作——因为他要么还没告诉别人这个点子，要么这件事看起来太没希望，没人被允许参与。即使有一个小组——他们也不可能多人编辑同一段代码——因为它变得太快。而项目从小开始——因为这个点子最初就小——他只是有一个想试试看的酷 hack。
更让人吃惊的是——官方批准的项目里有多少能把这 8 件事都做反。事实上——如果你看大多数组织里软件是怎么被写出来的——你几乎会觉得他们是在故意把事情做错。从某种意义上说——他们就是。自有“组织“以来——它的一项定义性品质就是——‘把个人当作可互换的零件来对待’。这件事对更可并行的任务（比如打仗）效果不错——历史上大多数时候——一支训练有素的职业士兵军队都能赢过一支由个体战士组成的军队——不管后者多么英勇。但**’拥有点子’是非常不可并行的**。而程序就是点子。
“组织讨厌依赖个人天才”——这件事不仅是真的——这是一个同义反复。这件事被刻进了’组织’的定义里——至少在我们今天的’组织’概念里。
也许我们能定义一种新的组织——它把个体的努力组合起来——但不要求他们可互换。市场也许就是这种组织形式——虽然把市场说成’退化情形’（即在’真正意义上的组织不可能时’你默认得到的东西）也许更准确。
我们大概最多只能搞出某种 hack——比如让一个组织里’编程的部分’按和其他部分不同的方式运作。也许最优的解是——大公司根本不要试图自己开发点子——而是直接买。但不管最终的解决方案是什么——第一步是要意识到这里有一个问题。“软件公司“这个词组本身就有内在的矛盾——这两个词在朝相反方向拉扯。任何在大型组织里工作的好程序员——都会和这个组织产生摩擦——因为组织被设计来阻止程序员所追求的东西。
好的程序员仍然能完成大量的事——但这经常需要他们对雇主进行某种事实上的反叛。也许如果更多人能理解：程序员表现出来的行为是被他们工作的需求所驱动的——这件事会有帮助。他们不是因为不负责任才长时段连轴转、忽略一切其他义务、不写规格说明就直接埋头编程、并把已经能跑的代码重写一遍。他们也不是因为不友善才更愿意一个人工作，或者对探头进门打招呼的人嗯嗯哼哼。这一堆看似随机的恼人习惯有一个统一的解释——’把程序装进脑子里’这件事本身的力量。
理解这一点是否能帮到大型组织——我不太确定；但它一定能帮到大型组织的对手。大公司最弱的那一点是——它们不让单个程序员做出伟大工作。所以——如果你是一家小创业公司——这就是你应该攻击它们的位置。去攻那种“必须由一个大脑解决“的问题。