Question

著名散文家E.B.怀特说过，“最好的文字来自不停的修改”。所有优秀作家都知道这一点，它对软件开发也适用。设计一样东西，最重要的一点就是要经常“再设计”，编程尤其如此，再多的修改都不过分。

为了写出优秀软件，你必须同时具备两种互相冲突的信念。一方面，你要像初生牛犊一样，对自己的能力信心万丈；另一方面，你又要像历经沧桑的老人一样，对自己的能力抱着怀疑态度。在你的大脑中，有一个声音说“千难万险只等闲”，还有一个声音却说“早岁哪知世事艰”。

这里的难点在于你要意识到，实际上这两种信念并不矛盾。你的乐观主义和怀疑倾向分别针对两个不同的对象。你必须对解决难题的可能性保持乐观，同时对当前解法的合理性保持怀疑。

做出优秀成果的人，在做的过程中常常觉得自己做得不够好。其他人看到他们的成果觉得棒极了，而创造者本人看到的都是自己作品的缺陷。这种视角的差异并非偶然，因为只有对现状不满，才会造就杰出的成果。

如果你能平衡好希望和担忧，它们就会推动项目前进，就像自行车在保持平衡中前进一样。在创新活动的第一阶段，你不知疲倦地猛攻某个难题，自信一定能够解决它。到了第二阶段，你在清晨的寒风中看到自己已经完成的部分，清楚地意识到存在各种各样的缺陷。此时，只要你对自己的怀疑没有超过你对自己的信心，就能够坦然接受这个半成品，心想不管多难我还是可以把剩下的部分做完。

让这两股相反的力量保持平衡是很难的。初出茅庐的年轻黑客都很乐观，自以为做出了伟大的产品，从不反思和改进。上了年纪的黑客又太不自信，甚至故意回避一些挑战性很强的项目。

任何措施，只要能让“再设计”周而复始地进行下去，就都是可取的。文章可以修改到你满意为止，但是软件的修改通常来说可以无休止地进行下去。文章的读者不可能抱怨修改后新增加的内容让他们前后的思想产生了不协调，但是软件的使用者就会抱怨修改后的版本有不兼容问题。

用户是一把双刃剑。他们推动语言的发展，但也使得你不敢对语言进行大规模改造。所以，一开始的时候要精心选择用户，避免使用者过快增长。发展用户就像一种优化过程，明智的做法就是放慢速度。一般情况下，用户比较少意味着你任何时候都可以加大修改的力度。这时，对语言规格做出改变就像撕绷带，当你感到痛苦的一瞬间，痛苦就已经成为了回忆。如果用户数量庞大，修改语言带来的痛苦就将持续很长时间。

大家都知道，让一个委员会负责设计语言是非常糟糕的主意。委员会只会做出恶劣的设计。但是我觉得，委员会最大的问题在于他们妨碍了“再设计”。在委员会的主持下，修改一种语言是非常麻烦的事，没有人愿意自讨苦吃。而且，即使大多数成员不喜欢某种做法，委员会最后的决定往往还是维持现状。

就算委员会只有两个人，还是会妨碍“再设计”，典型例子就是软件内部的各个接口由不同的人负责。这时除非两个人都同意改变接口，否则接口就无法改变。因此现实中，尽管软件功能越来越强大，内部接口却往往一成不变，成为整个系统中拖后腿的部分。

一种可能的解决方法是，将软件内部的接口设计成垂直接口而不是水平接口。这意味着软件内部的模块是一个个垂直堆积起来的抽象层，层与层之间的接口完全由其中的一层控制。如果较高的一层使用了较低的一层定义的语言，那么接口就由较低的一层控制；如果较低的一层从属于较高的一层，那么接口就由较高的一层控制。