书名:创意选择

    作者:[美]肯·科钦达

    译者:高源

    ISBN:9787521709216

    中信出版集团制作发行

    版权所有?侵权必究

    前言 创造卓越软件的方法——创意选择

    这本书记录了我在苹果15年的奋斗经历，你将看到我在这

    15年中为开发卓越的软件而付出的努力，以及与之相关的故事

    和我的一些观察。如果你想了解给史蒂夫·乔布斯做示例程序

    演示的场景和实际体验，或者iPhone(苹果手机)的触摸屏键

    盘为什么会变成现在的样子，或者是什么塑造了苹果的独特文

    化，请继续读下去。

    我会告诉你当一名苹果软件工程师是怎样的体验：在一家

    要求严苛的公司工作，我们必须承担其中的压力和喜悦；在与

    孤独为伴、殚精竭虑、不断敲打键盘并成功地让计算机增加了

    新功能后，我们这群开发者又会从内心迸发出欣喜和激动。

    作为苹果程序员团队的一员，我将与你分享这个群体的故

    事：一小群极其内向的程序员是如何在仅有梦想、目标的情况

    下，不断发挥聪明才智，创造出网络浏览器以及触屏手机操作

    系统的。

    此外，我还将介绍，作为整个苹果产品开发体系的一部

    分，程序员们是如何配合其他相关人员的工作的。比如，你会

    了解当设计师将软件的视觉效果和质感变得更加精致、优雅

    时，我们感受到的喜悦；你也会感受到在向同事、主管和不停

    地提出“无理”要求的高管们展示工作时，我们承受的重压。按照苹果的方式打造产品需要很多方面(工业设计、硬件

    工程、市场营销、法务以及管理一个庞大的全球供应链等)的

    努力，但要理解什么成就了苹果，什么是苹果真正的精髓，我

    认为关键在于理解软件。我将带领你走进这个程序员的栖息

    地，你会看到软件从一堆草稿纸中逐步诞生的过程，以及我们

    怎样赋予它们灵魂。其他公司可能也会设计外表美观的硬件、在市场营销上投入重金、聘请优秀的律师、大规模制造相关配

    件，但没有哪家公司像苹果一样，用卓越的技术和匠心把软件

    打造得如此直观，如此富有趣味。如果说苹果产品有什么神奇

    的魔力，那么它一定是软件的功劳，而我将讲述我们是如何创

    造苹果公司历史上一些最重要的软件的。

    当我2001年刚进入苹果时，台式计算机和笔记本电脑仍是

    公司最重要的产品。此时，在经历了11年的“流放”后，史蒂

    夫·乔布斯已经回归苹果4年了。尽管当时刚推出的彩色

    iMac(苹果电脑)已经使苹果成功地重新回到高科技领域中产

    品设计的领先地位，但在微软主导的市场中，苹果产品的占有

    率还不到5%。当时的苹果发烧友依然活跃，也热衷于苹果推出

    的产品，然而对于大多数普通消费者而言，Mac电脑是一台他们

    离开大学校园、走入社会后就再也不会使用的计算机。

    在我入职苹果公司4个月以后，情况开始发生变化。

    iPod(苹果公司设计和销售的系列便携式多功能数字多媒体播

    放器)的发布对我和其他人来说都是一个惊喜，iPod成为苹果

    产品由计算机开始转型为个人科技产品的强劲推动力。iPod的

    成功为公司赚来了现金和更为宝贵的信心，这些现金和信心支

    持了其后一系列影响深远的产品的开发及问世。这一发展趋势

    不断强化，并随着iPhone的推出到达顶峰。iPhone使苹果公司

    从科技领域里一个可有可无的小角色，成功跻身全球赢利能力

    最强的企业之一。

    我很荣幸能够成为苹果黄金时代的建设者和见证者，在一

    间小会议室就足够容纳iPhone这个秘密项目的全体软件工程师

    和设计师的时候，我就已经是其中一员了。如果你问我与第一

    台iPad(苹果平板电脑)有关的事情，我可能会把它称为K48

    ——在史蒂夫·乔布斯和市场营销部门敲定正式产品名称之

    前，开发人员对其使用的内部代码。就在我写本书前言的时

    候，几亿用户都在使用苹果的产品，如果把基于Safari(苹果

    浏览器)内核开发的一些在Windows(微软操作系统)及安卓系

    统上运行的浏览器的用户也算上，苹果产品的用户总量早已超

    过10亿，甚至可能达到了20亿。

    但我们从未把这个庞大的数字放在心上，因为我们的注意

    力全部集中在各种各样的细节上。在苹果工作的每一天，你都

    像在一所专注于设计专业、以高科技和产品创造力为核心课程

    的大学里读书，你做好准备，以应对随时可能出现的考试。我

    们始终处于高强度工作的状态，坚持将每一件事情做到极致，尽管不是刻意地这样做，但经过日积月累，我们探索出了一种

    对开发卓越软件非常有效的工作方法。

    我希望与读者分享这种方法，在这里我会详细阐述我们的

    工作方法。在讨论这个话题之前，我总结了对苹果软件的成功

    有重要影响的7个要素。(1)灵感：发挥想象力，大胆设想什么是可能实现的。

    (2)协作：与他人保持良好的合作，互通有无，优势互

    补。

    (3)技艺：反复实践直到取得高质量的结果，精益求精。

    (4)勤奋：坚持做看似枯燥却必要的重复性工作，不要依

    赖走捷径，也不要在努力程度上打折扣。

    (5)决断力：做果断的决策，拒绝推迟或拖延。

    (6)品位：培养敏锐的判断力，寻找能使整体达到和谐愉

    悦的平衡点。

    (7)同理心：尝试从他人的视角观察世界，创造适应他们

    的生活、满足他们的需求的优秀产品。

    在苹果，没有任何一本公司指南会写明以上内容，没有人

    为新员工总结这个清单，也没有谁会在苹果公司位于加利福尼

    亚州库比蒂诺总部的墙上看到号召大家“精诚协作”的标语。

    相反，我们认为，将一套固定的方法强加到每个人身上，反而

    可能会扼杀其本身存在的我们始终孜孜以求的创新能力。因

    此，我们的工作方法是在工作过程中潜移默化地影响彼此和传

    承下去。这种传承自上而下，来源于最顶层的毋庸置疑的权威

    ——永不妥协的史蒂夫·乔布斯；同时也自下而上，来源于一

    群你可能从未听说的设计师和程序员，而我要讲述的就是关于

    他们的故事。

    你翻开本书的原因可能多种多样，或者你想从业务一线的

    视角了解这家公司是如何运作的，或者你想了解你最喜欢的苹

    果产品背后的开发故事，或者你想探究一下苹果软件开发过程

    中的神秘技艺。但是，如果你把本书当作“让苹果成为伟大公

    司的7个要素”之类的指南来读，我希望你在阅读的过程中能够

    意识到，在条条框框的约束下行事绝非苹果的工作方式。

    虽然上述7个要素是在我们日常工作的基础上提炼出来的，但它们代表了长期的探索。我们在工作过程中形成的创造性方

    法是本书要介绍的重要内容之一。所有的软件工程师都全身心

    地投入产品开发，随着时间的推移，我们会逐步探索出一种开

    发卓越软件的方法，这是一个进化的过程，是我们以目标为导

    向并集中精力解决当下问题的努力的结果。我们从未指望自己

    在某一个瞬间灵光乍现，立刻解决棘手的问题，事实上，我们

    几乎没有经历过类似的尤里卡时刻。你在后文中可以看到，即

    便是在我经历了两次重大突破后，也没有人在苹果公司的园区

    里面像阿基米德一样裸奔。在现实世界里，我们作为一个团

    队，一步一步有计划地前进，从提出问题到产品设计，到样品

    演示，再到产品发布，我们采用新概念并尝试各种各样的方

    法，以求尽善尽美。我们将7个要素排列组合，针对不同的情况

    提取其中的某几个“分子”为我们所用。比如，在制作初始示

    例程序时，我们需要灵感和决断力；在给团队成员提供某个具

    体问题的反馈时，我们需要将协作、技艺和品位结合起来；而

    在开发消费者能够轻松使用的软件时，勤奋和同理心则是必不

    可少的。除了充分运用7个要素的排列组合，我们还会在其中添

    加一些个性化的因素、一点儿属于我们自己的东西，就像漫威动画里的“额外维度魔神”一样，通过将我们的目标、想法、努力，以及所有要素和“分子”融合在一起，我们总结了自己

    的方法，这种方法被我称为创意选择。

    第1章 向乔布斯做示例演示

    一阵震动声传来，我低头看向握在手中的iPhone，在过去

    半小时里，我一直紧张地把它在两手之间倒来倒去。而此刻，我终于收到了这条一直苦苦等待的信息：

    “现在可以过来了。”

    我立即回复：“好的。”

    一阵震动声传来，我低头看向握在手中的iPhone，在过去

    半小时里，我一直紧张地把它在两手之间倒来倒去。而此刻，我终于收到了这条一直苦苦等待的信息：

    “现在可以过来了。”

    我立即回复：“好的。”

    我当时正在位于加利福尼亚州库比蒂诺市的苹果总部“无

    限循环”2号办公楼的会议区等候通知，在收到信息前，我坐在

    椅子上，手肘撑在膝盖上，身体前倾。尽管皮质的椅子非常舒

    适，我的内心依然惴惴不安。信息已送达，我第一时间起身离

    开座椅，将iPhone放回口袋，快速穿过一条安静的走廊，在一

    间被称为密室的会议室门口驻足。这扇门被打开之后，我将向

    史蒂夫·乔布斯展示我最近更新的示例程序。史蒂夫可以预言未来

    2009年夏末，我正在为当时尚未命名的一款平板电脑开发

    软件原型。两年多以前，苹果正式推出了iPhone，正如它一经

    问世便俘获了电子产品发烧友的目光一样，iPhone不断地在大

    众市场上攻城略地，销售额的增长气势如虹。现在，新的任务

    ——为这一划时代产品的后续升级产品提供软件支持——又落

    在我们iOS软件开发团队的身上。

    其实，我本人从2005年开始就参与了iPhone的研发，在此

    期间我经历了重重磨难，最终柳暗花明，这些经历我会在第6章

    中与大家分享，我当时的职责是开发键盘操作软件，该项课题

    的重中之重正是我负责的自动纠错功能，这一功能可以将你输

    入的zhen’qur自动纠正为zheng’que。

    在iPhone的研发过程中，我们很慎重地将键盘操作软件认

    定为一个科研课题。当着手开发iPhone的触屏操作系统时，我

    们根本不知道在一片小小的触摸感应玻璃上打字是否具备技术

    上的可行性，也就是说，我们所做的一切很可能是徒劳的。尽

    管今天虚拟键盘已随处可见，但当时以黑莓为代表的主流智能

    手机都配备具有真实击打触感的巧克力键盘，而iPhone要配备

    的是对指尖触摸毫无反馈的极小的虚拟按键。

    因此，有效的自动纠错功能十分重要，我自始至终都在担

    心自己撰写的纠错代码会让iPhone成为科技圈的又一个笑柄。

    没有一个苹果员工想重蹈Newton(苹果公司于20世纪90年代推

    出的个人数字助理产品)的覆辙，这个在20世纪90年代曾被苹

    果寄予厚望的PDA(个人数字助理)产品在问世后惨遭滑铁卢，一蹶不振后再无东山再起之日，究其原因，有一大部分要归咎

    于乏善可陈的文字输入系统，Newton未能像它曾被期待的那样

    成为普罗大众不可或缺的数码伙伴。

    苹果公司无处不在的保密制度使我的开发任务更加复

    杂，“Purple”(紫色)是iPhone项目在研发时的内部代码，与Purple相关的所有细节均受到了必要的信息保护。2007年1

    月，在史蒂夫的公开演讲前，几乎没有人有机会试用Purple，甚至不能看一眼Purple的操作系统，所以我的键盘项目被视为

    一个真正的科研课题，在面向消费者之前，我只能在很少的内

    部使用者口中获得极其有限的反馈信息，这几乎相当于在

    iPhone上市后才开始在大范围人群中做大规模的使用试验。也

    许你现在能够理解我的紧张了。

    站在“密室”门口，我无暇回顾由iPhone紧张的开发周期

    带来的压力，我的注意力集中于当下的任务——给史蒂夫做最

    新版本的示例程序演示。这个将在随后被命名为iPad的平板电

    脑会使用与iPhone相同的操作系统，但iPad的屏幕更大，这一

    变化会给键盘操作带来一系列新挑战，我已经做好了其中一个

    难题的解决方案，并将其展示出来。这样的示例程序演示贯穿

    了整个苹果软件的开发过程，是一切开发工作的基础。正如我

    现在正在讲述的iPad软件演示案例一样，你会在本书里看到各

    种各样的示例程序演示的故事。在开发Purple智能手机的过程中，我从未向史蒂夫做过示

    例演示——在组织架构里级别更高的人会承担这项任务。显

    然，虚拟键盘在iPhone上的成功运用提升了我在公司内部的地

    位，尽管我的上级并未明说，但在我的能力被事实证明后，他

    们邀请我与史蒂夫见面的举动使我确信，正是这一功劳让我获

    得了当面向这位大名鼎鼎的首席执行官史蒂夫·乔布斯汇报的

    资格。

    这是我第二次向史蒂夫做示例演示——第一次发生在短短

    几个星期之前，当时我向他展示了为iPhone 4设计的准备在高

    分辨率视网膜屏幕上显示的字体选项，那次演示非常顺利，我

    的再次受邀让我认为自己已经进入需要定期向史蒂夫演示示例

    程序的核心开发团队，我并不清楚有资格进入这个小圈子的人

    到底有多少，但我相信人数并不多，可能只有几十。当然，其

    中还有更核心的小圈子，因为当我还站在走廊等待进入密室的

    指示时，里面已经有人与史蒂夫促膝长谈了。

    史蒂夫是公司里所有圈子的中心。5年来，他两次因身体原

    因休假，此时他刚刚结束第二次休假，回归公司数月。在身体

    状况允许时，他会亲自做出关于产品的一切重要决定。不间断

    地进行示例评审就是他决定苹果软件的界面、观感以及功能的

    最主要方式。

    作为程序员，我感觉为史蒂夫做演示就像参拜德尔斐神谕

    一样，示例演示就是我提出问题，而史蒂夫的回复就是最终的

    答案。不过人们从神谕中得到的往往是令人困惑的隐喻，而从

    史蒂夫那里得到的则是直截了当的结论和要求，他的回答始终

    明确而清晰，要么会批准你的示例演示，要么会明确要求下一

    次他要看到完全不同的东西。尽管如此，“史蒂夫之谜”依然

    存在，无论你的工作成果多么完美，或者在他之前的初步审查

    中进展得多么顺利，你永远都不知道他会产生怎样的反应。有

    时，他会表达自己对一件事物的喜爱或憎恶，但话音未落便更

    改了结论；有时，这种想法上的改变会发生在一两天之后；有

    时，一旦他的意见表达了出来，很多年都不会改变。

    史蒂夫的情绪也难以捉摸。在任何时候，他都可能因为自

    己不喜欢你的示例而对你大声斥责，没有人能幸免于此——无

    论是与他朝夕相处的高管还是像我这样默默无闻的程序员。这

    是向史蒂夫直接汇报必须付出的代价，你要么接受，要么干脆

    放弃面对面演示的机会。任何人要想在这辆极端情绪的过山车

    上坚持下来都不容易，的确有人会求饶。一位才能非常出众且

    经验丰富的同事直接跟我说，他正是因为无法忍受史蒂夫在面

    对面会议中表现出的待人方式，才拒绝再次为史蒂夫当面演示

    示例程序。尽管我的这位朋友对史蒂夫的脾气颇有怨言，但他

    仍然尊重和欣赏史蒂夫对产品的品位和商业判断。

    虽然史蒂夫的观点和情绪很难预测，但他对产品的热情是

    完全可以预测的。他希望苹果的产品能做得很好，因此他坚持

    参与整个过程，通过他的评论来指导产品的发展。正因为这

    样，我才等着给他看我的演示。他想看看我最近的进展，然后

    用他的反馈和建议把工作推向他理想中的水平。

    毫无疑问，作为新产品线中用户界面的重要元素，我们研

    发的平板电脑键盘必须得到史蒂夫的亲自验证和批准。每一次评审时，他都会非常详细地说明下一次他想要看到的成果，比

    如“在这两个元素之间增加一点儿空间”，或者是“把这张图

    表里面的绿色替换成蓝色”，或者是“这些统统都不行，下次

    要给我更多的选择”。更多时候，他试图让产品尽可能地直观

    和简洁，为此他愿意付出时间和努力，并愿意通过施加影响力

    来保证这一点。通过评审示例程序，提出具体的改进要求，重

    审反复更新后的示例程序，给出最终的肯定意见，史蒂夫能够

    将产品变成他想要的样子。就像传说中的神谕一样，史蒂夫可

    以预言未来。

    进入密室

    一阵门把手转动的声音传来，我朝密室的方向看去，门只

    开了一条缝，一丝光亮从密室的门缝中露出，照亮了昏暗的走

    廊。在我的眼睛适应了光源后，我看到了iOS工程副总裁亨利·

    拉米雷斯那张微笑的面孔。亨利将门开到刚好足够脑袋探出来

    的角度，即便到了这一刻，我还是没能理解这个戏剧化的姿势

    到底是什么意思。我们都知道，当史蒂夫在密室里做示例评审

    时，汇报人需要静悄悄地进出。但现在不是解惑时间，我走向

    门口，心中感到一阵紧张。

    亨利的岗位职责要求他既与史蒂夫等公司高层沟通，又与

    我这样的程序员互动。他带领的软件工程师团队既要为iPhone

    自带的应用软件(信息、邮件、日历、Safari浏览器等)负

    责，又要向世界各地的程序开发者提供软件开发工具包，使程

    序能够在iOS应用程序商店上架销售。史蒂夫需要亨利去传达示

    例评审会议的决定，亨利因其标志性的自信和谦虚而胜任这个

    角色。他蓄了满脸的胡须并经常打理，在苹果工作了20多年，他的胡须变得不再乌黑，像是撒上了盐和胡椒粉。他是一位口

    音很重的法国人，有时我仅能通过上下文来理解他表达的意

    思，他的有些英文单词的发音听起来很奇怪。我感觉最有趣的

    是build(构建)这个单词，亨利在说这一通用的编程术语时，我听到的总是bweeld。几星期前，亨利再次成为我的直接上司，之所以说“再

    次”，是因为几年前，在iPhone项目尚未开展的时候，我曾向

    他汇报工作，当然那时我们俩的职位都与现在不同。一个很偶

    然的机会，我亲眼见证了亨利在强压状态下仍能保持冷静和耐

    心的能力，这个小插曲将在后面与各位分享。

    这么多年来，我一次又一次地感受着他的冷静。在向史蒂

    夫做示例演示的过程中，无论气氛多么紧张，他都始终保持镇

    定并一直微笑。亨利是程序员团队和公司里最难取悦的领导者

    之间的缓冲地带，他将高层指示中难以入耳的苛责进行过滤，然后传达至每位程序员。如果他对我说“我刚听说史蒂夫发现

    了一个系统漏洞”，那么史蒂夫的原话可能是“今天的版本里

    面大写锁定键真不好用，难道这群蠢货没有测试过这个键盘

    吗？”每当亨利筛选出有用的信息并将其传达给我们的时候，我总会对他能够顺利搞定所有事情的信心敬佩不已，他似乎很

    清楚，我一定会立刻放下手头的所有事情第一时间修复漏洞，而给我施加压力并无益于问题的解决。亨利的行事方式使得他

    成为有点儿不近人情的首席执行官的互补搭档，他就像一阵保

    护我们不被史蒂夫的狂热灼伤的凉风，默默守护在我们身边。

    “进来吧。”亨利笑着说，他将门开得稍大一点儿以便我

    进入。我迈开步子穿过走廊，深深地呼吸。示例评审正在进

    行，或者说我认为它正在进行。进入密室后一向右转，我便看

    到了史蒂夫，他正在用手机通话。

    “嗯，听起来不错。”史蒂夫倚靠在一张办公椅上说，他

    的目光透过圆框镜片直视天花板，iPhone紧贴耳边，身上穿的

    黑色高领毛衣的袖子被撸到前臂的中部，两腿在身前交叉，牛

    仔裤的裤脚移到了小腿处，露出了穿在灰色跑鞋里面的黑色袜

    子。这是史蒂夫的标准着装。他看起来并未因为疾病而精力不

    足，此时此刻，他正全神贯注于这次很重要的通话。我愣了一

    两秒，但迅速意识到自己应该静静地站在原地，不要试图引起

    史蒂夫的注意。我被叫进来继续等待。

    被迫听一位有权势的人物通话可不是一件舒服的事情，我

    自然也不愿意表现得像在偷听一样，我把手放在身后打量起这

    间会议室。

    密室大概30英尺 长，15英尺宽，主色调为褐色，没有窗

    户。会议室的中间对着门口的方向放着一个沙发，将整个房间

    的空间分成两部分。一对8英尺长的桌子挨着靠门这边的墙平行

    摆放，这里形成了一个做示例演示时可以利用的空间。沙发和

    两张长桌首尾相接形成了U字形，史蒂夫的办公椅刚好位于字母

    的一个拐角处，我站在门口靠近U字的开口处朝右看去，在离我

    最近的一张桌子上，放着iPad原型机，我即将演示的最新示例

    程序已经被下载到原型机里了。

    我再度环视整间会议室，无论多少次走进这间屋子，我都

    有相同的感觉。房间内的装潢有些破旧，根本不像高度重视设

    计品位的苹果公司使用的会议室。离我较远的那张桌子上只摆

    放了一台iMac，它身后的墙上被订上了一张歪歪扭扭的Mac OS

    X 10.2的无框海报，这个版本的昵称是美洲虎。如果说这张破

    烂的海报本身不能体现它的悠久历史的话，那么海报中以皮毛

    和斑点做底、有衬线的“X”则让人很清楚这张海报已经有些年头了——这个版本的软件已经推出若干年了。从那以后，这

    个“X”的标志通过不断更新被逐渐改变为金属灰色，最后又变

    成了无衬线的字体。这些桌子倒是因不起眼而引人注目，它们

    可不是你想象中的苹果零售商店里用来陈列商品的同款浅色桌

    子。这些桌子是灰色的，桌面用福米卡塑料贴面，是标准的办

    公家具。在我左边的那面墙，上至天花板下至踢脚线都被白板

    占据，白板上面沾满了笔迹，这些笔迹又在反复的擦拭中被抹

    掉了。接下来，映入我眼帘的是那张沙发，沙发并不干净，坐

    在上面就好像置身于大学联谊会里面满是污秽的沙发垫上一

    样。在沙发后面的那一半空间里，有几个豆袋椅被遗弃在角落

    里，像是对早期硅谷的致敬。整体来说，密室就像一个没有什

    么特别之处的书房。但这是一个非常重要的房间，经常被史蒂

    夫用来评审示例程序，只是它本身并非那么引人注目。

    观察这间会议室花了我一两分钟的时间，但是史蒂夫仍没

    有显示出中断通话的迹象。我下意识地觉得有些尴尬，因为我

    是整个屋子里唯一站着的人，亨利坐回沙发上之后，那里已经

    没有多余的空间了，而史蒂夫占据了唯一的一把椅子。看起

    来，在史蒂夫结束通话以前，我只能保持现在的状态。某一

    刻，我看向亨利，他向我挑了挑眉毛，耸了耸肩，好像在

    说“我也不知道究竟还要等多久”。我不知道亨利为什么要在

    这种情况下让我进来，但还是那句话，这不是答疑解惑的时

    候。

    1. 1英尺≈0.3048米。——编者注

    2. 这里的Ⅹ表示罗马数字，苹果曾声明这个产品正确的名字是“Mac O-S

    10”。这个来自公司旗舰产品的命名规则在多年后被用到了iPhone Ⅹ上。很多

    人把Ⅹ当作英文字母x来发音，而不是数字10，不过谁会指责消费者呢？苹果之核

    与亨利一起坐在沙发上的人组成了软件开发的真正的核心

    圈子，版本评审时，他们是仅有的史蒂夫希望坐在自己身边给

    予建议、提供咨询和进行思维碰撞的人。他们参与了iPhone的

    评审过程，现在又轮到了iPad。这里的每一个人都通过不断提

    出有助于改进产品的反馈意见，成功地获得并坐稳了现在的位

    置。

    在亨利左边就座的是他的上级斯科特·福斯特尔——时任

    iOS软件工程高级副总裁，直接向史蒂夫汇报。正是斯科特给了

    我在密室直接向史蒂夫汇报的机会，他希望我在汇报时尽量简

    洁，突出重点。尽管他并未直接提出这样的要求，但通过他作

    为最高级别管理人员主持的早期评审会议中的成功案例和失败

    案例，我已经很清楚自己需要怎么做了。在密室中进行的评审

    显然重要得多，因为他的老板就座在会议室里。斯科特是我的

    上级和支持者，我在演示过程中的表现将对他产生重要影响。

    鉴于我仍处于进入核心圈子的考察阶段，我猜测，只要搞砸一

    次，我可能就会被斯科特从这个小圈子中除名。尽管他从未明

    说，但据我所知，只要得到一个类似于“蠢货”的评论，我就

    永远不会回到这里了。

    斯科特的地位并非岌岌可危，他与史蒂夫的关系十分稳

    固，他们的合作关系可以追溯到NeXT时期，NeXT是史蒂夫1985

    年被苹果解雇后独立创办的公司。自1996年苹果收购NeXT以

    来，史蒂夫和斯科特就开始在软件方面紧密合作了。

    我认为，史蒂夫非常重视斯科特在将新技术集成于成熟软

    件产品方面的想象力，斯科特很擅长新技术和成熟软件产品的

    结合。如果程序员告诉斯科特，一个正在开发的应用于触屏系

    统的软件可以使系统准确区分快速滑动和缓慢平移，那么他会

    立刻构想出一个用户使用场景，手指在列表的某一行(比如收

    件箱里的一封邮件)上轻轻滑动，就可以将其删除。

    我们在苹果创造出来的软件就源于这种细节的一次次积

    累。史蒂夫看中斯科特，不仅因为他可以自己做出这些细节的

    创新，更在于他可以创建和领导团队将这一过程不断规模化复

    制。这是史蒂夫心目中的苹果使命的一部分，苹果产品开发的

    最显著特点是：将科技与人文融合，利用最先进的软件和硬

    件，使设计和文化的元素融入其中，这样创造出来的产品和功

    能会非常有用，能让人们的日常生活充满乐趣。斯科特之所以

    能够坐到现在的位置，是因为他可以将科技与人的连接做得无

    人能出其右，并且他似乎可以轻而易举地做到这一点，完全不

    用停顿，也不用清嗓子，就能形成源源不断的赚钱效应。他的

    机敏有时会令人紧张。我发现，斯科特总是能让我意识到自己

    需要讲得更快一些，这样他才不会打断我的发言。

    坐在斯科特旁边的是他手下的另一位高级经理格雷格·克

    里斯蒂，他是人机界面团队的负责人。人机界面团队中的软件

    设计工程师决定了iOS和Mac软件及服务产品所呈现的视觉、体

    验，以及系统功能背后的逻辑。我们在提到格雷格的团队时会使用简称HI团队，作为HI团队负责人，格雷格为我们应用程序

    和用户界面的设计拓展了广度和深度。格雷格是一个身着法兰

    绒衬衫、有吸烟习惯的纽约人，他像一本活的百科全书，熟稔

    计算机技术的发展历史，对模拟硬件和数字硬件的知识如数家

    珍，并且对易使用软件的开发有着与生俱来的第六感。几年

    前，在开发iPhone键盘的过程中，格雷格曾给我提供了至关重

    要的建议。当我被难题困住而感到非常绝望的时候，他直截了

    当地要求我解决一个我一直以来都在回避的问题——要让每一

    个按键都变得比指尖还要小，并且在现有自动纠错代码的基础

    上做必要的改进。格雷格经常能够洞察到某些复杂的改进路径

    可能才是提高产品易用性的最优方式；他从来都不是一个容易

    被糊弄的人。打个比方，他像猎人一样绕着捕熊器巡视，捕捉

    每一个因懒惰而试图用借口逃脱责任的人。如果你想用一个粗

    制滥造的示例程序蒙混过关，那么等待你的必然是格雷格尖锐

    的驳斥。他在公司里并不是很受欢迎，但是，对那些严格要求

    自己且勤勉尽责的人，他绝对会提供毫无保留的支持。(免费

    书享分更多搜索@雅书.)

    在沙发最右侧就座的是巴斯·奥尔丁，这个位置离史蒂夫

    很近，近到史蒂夫伸出腿就可以踢到他。巴斯是HI团队里的一

    位设计师，他在创建图解、动画以及示例演示方面有着天才般

    的造诣，他的娴熟技艺对iOS设备最终呈现出来的观感起到了重

    要作用。当我们要解决在没有鼠标或方向键的情况下上下移动

    一个项目列表的问题时，巴斯创造了“惯性滚动”，即在用户

    滑动屏幕时，列表随之滚动，用户反复滑动屏幕，列表滚动速

    度加快，用户停止滑动后，列表会逐渐降低滚动速度直至停

    止。如果滚动到页面底部，列表就会反弹。如今，我们所有人

    都觉得这种方式是理所应当的，只是因为巴斯的解决方案完美

    地呈现了我们心目中的这种交互应有的样子。巴斯个子很高，很瘦，他的短发一根一根地竖立在头顶。巴斯习惯于以一

    声“哈哈”作为一句话的结尾，好像你和他正在分享同一个笑

    话。巴斯是史蒂夫最欣赏的人之一，也是我最喜欢的人之一。

    我很喜欢与他共事，即将向史蒂夫演示的示例程序就是我们最

    新的合作成果。

    史蒂夫的通话仍在继续，我再次看向这些坐在沙发上的

    人，他们的表情和姿势让我意识到自己并不是这间会议室里唯

    一想要避嫌的人。这个场景看起来有些离奇，而且似乎带着一

    点儿梦幻的色彩。我的目光又落在了史蒂夫身后演示桌上的

    iPad上，它依然静静地躺在那里，不会凭空消失，但是我开始

    担心起来：它的电池充满了吗？这个梦幻的场景会不会变成一

    场梦魇？简洁是灵魂

    这次键盘方案示例演示的工作实际上从一个月以前——我

    被提升为iPhone软件首席工程师(见图1-1)之后不久——就开

    始了。

    图1-1 我的工作名片

    这份新工作的内容是比较开放的，我的任务是为优化现有

    软件去开发和研究新项目。在我苦思冥想要怎么开展工作时，HI工作室成为我每天都要拜访的地方。一天，我放下手头的工

    作去找巴斯，与平时一样，他正在做一件很酷的事情。

    他用Adobe Director(多媒体项目的集成开发软件)制作

    了一份示例程序，即便在2009年，这个软件也已经是老古董

    了。多媒体出版业在20世纪90年代曾大规模地使用Director软

    件制作可以用光盘播放的内容，以及一些你可以经常在购物中

    心看到的供顾客查询某家鞋店或美食中心的互动内容。此后，Flash动画、网络以及移动计算技术的兴起让这款软件逐渐被人

    们遗忘，但是巴斯很喜欢这个软件，主要原因是Director软件

    中面向对象的语言是Lingo语言，而他本人精通Lingo语言，因

    此他可以利用Director软件，用简单的图片、动画和几行Lingo

    语言代码，制作出表面上看起来跟Mac计算机和iPhone的交互界

    面完全相同的示例程序。尽管他制作出的示例程序并非消费者

    使用的“真”软件，但巴斯可以利用Director软件在很短的时

    间内呈现出类似于真实软件的效果以供开发者参考。

    当巴斯又开始用Director软件进行创作时，我站在他身后

    观察，在他的Mac计算机屏幕上，我看到了一个似乎很像拉长的

    iPhone键盘的东西。背景、按键以及字母颜色都一样，但是键

    盘的整体形状比iPhone键盘更扁更长。巴斯对我说这是他设想

    的iPad键盘。他做这个示例程序是为了测试一些参数的变化。

    在键盘的边缘部分，巴斯做了一套屏幕控制键，当他按下这些

    按钮并滑动的时候，演示界面上的键盘背景、按键以及字母开

    始发生变化。他让按键时而变大，时而变小，他在浅色按键深

    色字母和深色按键浅色字母之间来回切换，他不断地调整空格

    键、删除键以及回车键的形状，随着这几个按键的变化，其他

    按键也随之调整形状以填补空白。每一个方案都配有一个精心

    制作的动画，并标示了改动的部分。巴斯在给我演示每一个方案时，都会简短地介绍该种方案的可行性和实用性。暂且不说

    屏幕上优美的画面简洁而完美地诠释了他的想法，仅是键盘的

    长宽比和布局就给我留下了深刻的印象。与我们在iPhone上应

    用的键盘相比，他对iPad触屏键盘的构想更像是台式机或者笔

    记本电脑上的键盘：标点符号键和shift键的位置与它们在标准

    键盘上的位置相同，在键盘最上方的数字键上，同时显示了我

    们熟悉的配对字符，比如，!和1在同一个按键上，@和2在同一

    个按键上，以此类推。

    几年前，巴斯和我合作设计了iPhone键盘，我们受限于

    iPhone的小尺寸屏幕，一直在苦思冥想。经过很多次试验后，我们从主键盘上移走了尽可能多的按键，以保证有足够的空间

    使经常使用的字母按键尽可能放大。即便是这样，一个普通大

    小的手指依然有可能同时覆盖两个甚至三个字母按键。在最终

    版本的设计稿中，我们将标点符号键和数字键放置在单独的界

    面里，用户需要在主键盘界面中点击“.？123”这个按键进行

    切换。我们担心用户会抱怨或者对这个不便利的设置感到愤

    怒，但结果是人们快速且平静地接受并适应了这样的变化。

    巴斯在向我逐一展示他为iPad设计的各种键盘方案时说，他想要在iPad大屏幕上配置一个更传统的键盘布局，就像他桌

    上的Mac计算机键盘一样。在我们聊天的过程中，巴斯从未停止

    手中的动作，他不停地移动滑动键和各种按钮，屏幕上的示例

    程序随之在不同的方案之间转换，这些方案都是基于平板电脑

    有着更大的屏幕从而可以在主键盘排布更多按键这个主题而设

    计的。巴斯给自己建造了一个键盘乐园，他的热情极具感染

    力，当他停下手中的动作，转过头来看我时，我脸上露出了抑

    制不住的笑容。

    我回到办公室，反复回想巴斯展示给我的示例程序，我在

    脑海中想象着这个键盘在我桌子上的iPad原型机里运行，而不

    是在他的Mac计算机上运行的样子，让我印象最深刻的就是巴斯

    关于增加更多按键的内容。这个方案看起来是很合理的，尤其

    是在我们已经有了足够的屏幕空间，可以使用更多按键的时

    候。我认为人们可能更喜欢直接在主键盘上寻找到句号和逗

    号，而不需要按“.？123”按键进行转换。

    我的目光在iPad原型机的屏幕和连接在Mac计算机上的键盘

    之间来回切换，我突然萌生出一个想法。我拿起iPad将其横置

    在Mac键盘的上方，我发现iPad屏幕长边的长度与键盘字母第一

    排的长度几乎相同，这让我意识到键盘第一排的10个字

    母“QWERTYUIOP”刚好可以按照原比例被直接复制到iPad虚拟

    键盘上。这样一来，在字母这排的上方就没有空间放数字了，但这样的设计可能也无伤大雅，因为iPhone的键盘排列就是这

    样的，只不过在更大的iPad屏幕上，这些按键的尺寸可以变得

    与Mac键盘相同。巴斯希望将Mac键盘完全复制到iPad上，而我

    的思路跟他的方案完全不同。

    现在，我们拥有了两个有趣的想法。我的方案能提供更便

    于打字的大按键，但这样用户就需要在其他界面寻找数字和标

    点符号；巴斯则希望用户能在主键盘上直接敲击数字和键盘，但是每一个按键都会变得更小。我决定自己动手做一个示例程

    序来模拟这两种方案的效果。在我升职的几周前，我一直负责键盘代码的日常维护工

    作，因此我十分熟悉键盘系统的软件，我可以在几天之内写出

    两套键盘方案，一套是巴斯的“更多按键”方案，还有一套是

    我设想的“更大按键”方案。用这套代码写出的示例程序比巴

    斯用Director软件做出来的更实用，因为巴斯提供的示例仅仅

    是用图片和动画模拟的，而我的示例则是可以在任何iOS应用中

    正常使用的“真实”键盘。

    我更深入地思考了一下，然后决定将“更大按键”方案的

    键盘布局尽可能地按照Mac键盘的尺寸呈现，把它设计成每行按

    键交错排布的样式。如果我能够模拟真实键盘的整体格局，也

    许Mac使用者会更习惯于使用iPad虚拟键盘。

    为了让设计更加准确，我必须做好测量工作。首先，我需

    要一把尺子。我把自己的抽屉翻了个底朝天，结果只找出了几

    个旧的RAM芯片、一些图钉以及若干iPhone原型机。我问了坐在

    旁边的同事，他们投来疑惑的目光并以耸肩作为回答——一个

    程序员要测量什么东西？我翻遍了走廊上的办公用品柜，仍旧

    没有找到尺子。然后，我想起来，在距离总部办公室约一英里

    的史蒂文森溪谷大道上，有一家塔吉特百货商店。

    在开车去塔吉特百货商店的路上，我一直想象我需要的尺

    子到底是什么样子的。它应该是一把给专业绘图人员使用的漂

    亮的、坚固的、用金属制成的尺子，是那种像是苹果出品的精

    确测量仪器。然而，我并没有在塔吉特百货商店里面找到如此

    美好的尺子，唯一在售的是一种一英尺长的略带黄绿色的淡蓝

    色塑料尺。它看起来很廉价，事实上也确实很便宜。当我发现

    我可以买一个相同颜色的塑料半圆量角器时，我还是把它们一

    起买下了。就这么决定了!

    带着两个新玩具(呃，应该说是工具)回到苹果办公室

    后，我开始测量相关物品的尺寸，测量对象包括台式机键盘及

    按键、笔记本电脑键盘及按键、iPhone屏幕及上面显示的虚拟

    键盘按键，以及iPad屏幕。我想要建立一个关于这些键盘元素

    的数据库，我需要一定的时间和精力来研究这些数据，理清这

    些数据之间的联系，建立一种直观体验。我把所有这些物件的

    尺寸和角度都记了下来，在Adobe Illustrator软件里面制作了

    一些框架草图，我将所有的草图叠放起来，苦苦地思索。我开

    始为两种键盘撰写代码，除了将最上方的功能键删除以外，我

    完全依照笔记本电脑键盘的样式来呈现巴斯的“更多按键”方

    案。至于我自己设想的“更大按键”方案，我参考iPhone键

    盘，但把delete键删除了，同时添加了一个shift键。我又思考

    了更多细节，并花了几天时间完成了这个示例程序的代码编

    写。鉴于iOS中已经有了一个用于切换语言的“地球”样式的按

    键，我把这两种方案视为两种可切换的新“语言”。在完成这

    项工作后，我将成果展示给巴斯。

    他对我的示例程序报以和蔼的微笑，这表明他很喜欢它。

    他还给出了一个建议，不要使用“地球”按键在两种界面之间

    切换，毕竟我们不是在切换语言。他认为我们应该在空格键旁

    边增加一个新的键盘切换键，按一下就可以将键盘按键放大，再按一下就可以将按键缩小，以便于使用更多按键。巴斯说他会为缩放设计一个动画，我认为非常棒。我回到自己的办公桌

    前，又开始了增加缩放键的工作。

    几天后，我们把所有的事情都搞定了，现在是时候给更多

    人展示了(见图1-2)。我们将这个键盘示例加入了下一次iPad

    整体评审的工作日程表中，亨利、格雷格以及斯科特将对众多

    最新的示例程序进行评审。在评审过程中，他们将决定每一个

    示例程序是否能够被提交到史蒂夫面前，预判亨利的程序员团

    队能否在日程表的剩余时间里完美地实现示例程序展示的功

    能，而且要保证低故障率。他们会非常谨慎地筛选提交给史蒂

    夫的示例程序，尽量回避史蒂夫可能非常喜欢，但我们还无法

    在产品中实现的那些东西。斯科特可不是在象牙塔里运营研发

    部门。能够提交给史蒂夫的示例程序一定是我们确保能实现

    的，因此，未经反复修改就通过评审的示例程序是极少见的

    ——一般要经历数周的反复反馈和修改。

    图1-2 巴斯的“更多按键”方案和我的“更大按键”方案

    iPad键盘示例程序却没有如此费劲儿，我们轻松地通过了

    在史蒂夫之前的评审。这主要归功于巴斯通过其自行设计的缩

    放动画活灵活现地展示了我们的构想。

    当你按下iPad示例程序中的zoom(缩放)键时，当前显示

    的键盘(比如，我的)会切换至另外一个(他的)，就像

    Keynote或者PowerPoint里面的“点击进入下一张幻灯片”一

    样。一个键盘的图像完全消失，屏幕上浮现出另一个键盘。巴

    斯还在动画中增加了缩放比例，在切换过程中，被切换的键盘按键逐步缩放至即将浮现的键盘按键的大小，最初这个缩放过

    程比较缓慢，然后逐步加快，当动画停止的时候，你会有一种

    终于降落了的感觉。这种效果是非常精细的，整个动画的切换

    过程还不到一秒，但是巴斯就是有办法让这些细节展示出来。

    当观察这个zoom键操控的动画时，你会觉得这两种键盘在做非

    常复杂的变形，但事实上它们并没有。从一个工程师的视角来

    看，这是相当难得的，因为这种简单的设计意味着我们仅用几

    个小时就可以将这个动画的程序代码编写出来，而且整体效果

    好得令人惊奇。这个动画看起来并不像在桌面上做展示的幻灯

    片那样从一张切换到下一张，当你按下切换键时，整个过程让

    你觉得当前这个键盘自动变成了另外一个键盘。这种感觉是浑

    然一体的，就是那种让苹果软件深入人心的不言自明的感觉。

    所有参加这次预评审的人都很喜欢键盘切换的概念。我们

    认为用户在使用新产品时会从这种复杂界面中受益，与iPhone

    相比，这是充分利用iPad大屏幕的绝佳方式。有些人会喜欢更

    多按键的布局，他们对完整的字母、数字以及标点符号的布局

    有着天然的好感。还有一些人可能喜欢更大按键的布局，他们

    的手指对合乎常规的按键布局有更敏感的触觉。这种可以切换

    的安排对两类用户都很友好。zoom键的存在让用户可以尝试两

    种新键盘，并可以随时切换而无须在系统中专门设置键盘偏

    好，更何况，巴斯设计的动画让这一切看起来非常特别。斯科

    特批准我们将该示例程序演示给史蒂夫看。

    1. 1英里≈1.6093千米。——编者注

    “圣人”的裁决

    “嗯，这一切听起来都很不错。”史蒂夫说，他的声音打

    破了密室里的沉寂，“好的，我会给你打电话的。”他的语调

    预示着通话即将结束，我们几个人立刻回到现实。

    “再见。”史蒂夫边说边将iPhone从耳边放回眼前，目光

    在屏幕上停留了片刻，按下了红色的挂机按钮。然后，他把

    iPhone放入了牛仔裤的前口袋，在椅子上起身坐直后，缓慢地

    转向我。

    我们俩的目光在空中交汇。多年以来，很多人都在评论史

    蒂夫的非凡能力，无论他告诉你什么，无论那些东西听起来多

    么难以置信，他都有能力让你相信。这种现实扭曲力场已经成

    为一个传奇。但是，当史蒂夫的目光锁定我的那一刻，我却感

    受到了相反的力量，现实扭曲力场的极性颠倒了。就像碰触了

    一个灯光的开关一样，史蒂夫开启了严肃的气场，这种气场能

    隔绝所有的言不由衷，将一切虚假的伪装清除殆尽。他的表情

    并非很明显的不友好，但他一定很清楚，他目不转睛的凝视可

    以让处于我这个位置的人感到恐慌，我也确实被这种凝视影响

    了，以至有些害怕。我把他的神情看作不会让我蒙混过关的信

    号，他已经准备好看我的示例程序了。

    斯科特站起来走到史蒂夫的椅子后面。“好的，让我们开

    始示例演示吧。史蒂夫，这位是肯，他之前负责过iPhone键盘的项目，现在他有一些平板电脑键盘设计的示例程序要向你展

    示。”尽管就在几周前，我已经当面向史蒂夫做过演示了，斯

    科特向史蒂夫介绍我的方式仍好像我们是第一次见面一样。如

    果史蒂夫很喜欢我之前的工作或者在之前的示例评审时记住了

    我，那么情况就不会是这样的，但他并没有表现出任何一种迹

    象。斯科特走到iPad原型机前，并没有从桌子上把它拿起，他

    按下home按键，当屏幕被唤醒时，滑动手指以解锁屏幕。

    史蒂夫仍然看着我。我接着斯科特对示例程序介绍的中断

    处往下说：“是的，我们设计了两种方案。一种是有更多的按

    键，就像笔记本电脑键盘那样；另一种是有更大的按键，就像

    放大版本的iPhone键盘一样。我们的想法是同时提供两种选

    择，通过zoom键在两者之间进行切换。”

    史蒂夫缓缓地转动他的座椅来到展示桌前，低下头，他面

    前的iPad是横置的，home键在整个平面的右侧。屏幕上正在运

    行的是iPad Notes应用的早期版本，插入点光标正在一个空白

    的文档上闪烁。屏幕底部当前显示的是巴斯设计的“更多按

    键”的键盘布局，它看起来和笔记本电脑键盘一模一样，只不

    过按键比标准版本的略小。史蒂夫的目光扫视了整个iPad屏

    幕，他的头部以极小的角度倾斜，在我看来，他应该在从正面

    和侧面尝试观察整个键盘界面的每一处细节。

    史蒂夫研究了很久之后，伸出手按下了zoom键，开启了巴

    斯制作的精美动画，键盘随之切换成我设计的“更大按键”布

    局。没有任何反馈，也没有任何可以猜出他想法的线索。史蒂

    夫就像一个正在第一次查看牌面的高额赌注扑克牌玩家。现在

    屏幕上显示的是另一个键盘，史蒂夫又开始了他的研究。他花

    了足足30秒仔细观察了屏幕上的所有细节。当觉得满意后，他

    再一次按下了zoom键，将“更多按键”的键盘布局呈现出来，跟示例演示刚开始时没有什么区别。史蒂夫又开始研究，他的

    想法和感觉依然让人捉摸不透。他再次按下zoom键，将界面切

    换至“更大按键”的布局，这一次，他简单地浏览了一下，确

    认已经看过全部两种设计，而这两种设计要等待他来选择。他

    转过来径直看向我(见图1-3)。

    “我们只需要其中一种，对吧？”

    这不是我想要的回答。我想我当时可能连吞咽这个动作都

    变得很困难。史蒂夫仍然在看着我，而我微微耸了耸肩，然后

    说：“是的……呃……我想是的。”

    史蒂夫稍稍打量了我一下，然后问道：“你觉得我们应该

    用哪一个？”

    一个非常简单的问题，需要我而且仅需要我来回答。史蒂

    夫的椅子和身体并没有转向屋子中的任何人。这是我的示例程

    序，他希望我来回答。

    然后有些事情就这么自然而然地发生了。我站在那里，史

    蒂夫的目光一直停留在我身上，等待我回复他的问题。我突然

    意识到我有自己的观点，应该知道如何回答。

    “是这样的，我在过去这些天里一直在用示例程序里的键

    盘，我已经开始喜欢‘更大按键’这个布局的键盘了。我想，既然我可以习惯通过触感打字，相信其他人也可以，自动纠错

    功能可以帮上大忙。”

    图1-3 评审示例程序时的史蒂夫

    史蒂夫继续看着我，他在思考我的答案。他从没有将眼神

    从我身上转移到其他人身上或者其他地方，完全沉浸在当下。

    就在这里，他认真地思考我关于下一个苹果重磅产品的想法。

    这是令人激动的时刻。他想了几秒钟，然后宣布了他对这次示

    例程序的最终决定。

    “好的，我们用‘更大按键’这个方案。”

    就这样，苹果的“圣人”发话了，关于软件设计的预言被

    大家知晓了，话音落定的同时，史蒂夫轻轻地点了点头。我的

    示例演示到此结束。格雷格、亨利和巴斯从沙发上站起来，他

    们用“干得好”和“演示得不错”等简短的句子表达了鼓励。

    我又变回了那个天生内向的人，在刚刚接受了远超我日常最高

    限度的关注度后，我看向地面。这间屋子里面的紧张气氛瞬间

    消散了。斯科特朝门口走了几步，暗示我此时应该离开以便他

    们进行接下来的工作。我打开了“密室”的门，斯科特静静地

    等在我身后准备关门，在我离开后他将继续在“密室”里工

    作。我向走廊迈开步子，就在门被锁上前，我听到史蒂夫

    说“谢谢”。史蒂夫只说了四句话

    德尔斐神殿的入口处上方有一个碑文，上面写着：“了解

    你自己。”它在告诫即将步入神殿的提问者，你所寻求的答案

    可能就在自己的内心深处。当我走出“密室”时，我对自己刚

    才的表现非常满意，我完全凭借自己的能力如实地回答了史蒂

    夫对示例程序的提问。

    这只是在这次示例演示之后我回想这段经历时的最初感

    受，而此后，我思考了更多。

    史蒂夫问我自己的想法其实是一个测试。在看过我的示例

    程序后，他想确认我是否能够胜任把苹果软件做得更好这项工

    作。如果我没有给出令人满意的答案，那么他会向会议室中的

    其他人提问。在座的其他人都是通过不断地经历类似的测试，以及持续交出优秀的工作成果来坐稳如今的位置的，他们成就

    了iPhone软件的每一个细节。如果我希望自己能够一直在密室

    中做示例演示，那么我只有不断地为他建言献策，并为公司做

    出卓越贡献，才能赢取未来的邀请函。当然，在此之后我做到

    了。在整个职业生涯中，我给史蒂夫做过很多次示例演示。

    对我来说，这就是写代码和影响所写的代码的区别。在这

    次示例演示里，我的想法得以贯彻到产品中，在最终问世的

    iPad里，除了删除掉zoom键之类的小细节，真正的键盘与我在

    会议室中演示的示例程序完全相同。我通过了测试。

    密室中的决策和发布软件之间的关系，也说明了在苹果公

    司里示例程序对我们的重要性。示例程序是将概念想法转变为

    软件的主要方式。这些示例评审会议的设置展示了我们是如何

    将软件打造得如此优秀的。

    这句表述隐含了一个假设，即苹果把创造伟大软件当作最

    重要的目标。我们做到了，而这一切直接来源于史蒂夫。他设

    立了公司的首要目标，无论是在公众场合演讲还是内部交流，他都始终强调这一点：创造伟大的软件是公司的核心任务。更

    重要的是，史蒂夫不仅在口头上重视这一目标，还表现在行动

    上，因此软件开发团队源源不断地制作示例程序，无论何时，只要有引人关注的新发现，史蒂夫总能抽出时间参加示例评

    审，从而亲眼见证“伟大产品的诞生”。他的参与使得整个项

    目一直保持不间断的进展和突破。

    我们只有把各种各样的示例程序汇总，才会形成一个完整

    的产品，因此，在密室工作的5个人和乔布斯一起形成了一个对

    整个过程有着关键影响的小圈子——可以创造出一个独立的首

    席执行官级别示例程序的团队。在这个小团队中，我们拥有我

    们需要的一切。我是程序员，巴斯是设计师，亨利、格雷格和

    斯科特是编辑者。在合作过程中，有些角色是可以互相转换

    的。巴斯有时会写点儿代码，他经常在不需要程序员的帮助的

    情况下，独立完成一个可以直接向史蒂夫演示的示例程序。在

    这次键盘示例程序开发中，我承担了部分设计工作，自行增加

    了“更大按键”方案。在我把“地球”键作为两种键盘的切换

    按钮后，巴斯承担了编辑工作，将其变更为zoom。决断力自始至终都非常重要。在把方案提交给史蒂夫之

    前，斯科特是执行主编，是那个“做决定的人”。苹果公司的

    每一次示例评审都有一个决策者，这个人是唯一有权力决定一

    个示例程序是否通过或者宣告接下来要做什么的人。不过，即

    使是在正式评审开始前，比如在巴斯和我这类比较有经验的开

    发者组织的会议上，我们每个人都可以决定自己负责的工作，以及我们是否有意愿为一个全新的想法或者进一步的改进付出

    额外的努力和时间。一旦我们与团队成员合作完成了为评审准

    备的工作，或者与级别较低的同事完成了某项任务，团队主管

    就是那个决策者。这个决策环在任何管理层级中都适用。在特

    别忙碌的时期，亨利会负责所有iOS工程师的示例评审工作，此

    时，他就是斯科特之前的全权决策者。我们必须在示例程序能

    够最终呈交给史蒂夫之前日复一日地制作海量的示例程序，这

    意味着我们的日常工作就是一座由示例程序、评审、决策构成

    的金字塔，史蒂夫的最终裁决位于塔尖。(免费书享分更多搜

    索@雅书.)

    判断是否要通过一项工作成果并不是唯一的决策内容。当

    斯科特决定选择把我，而不仅仅是我的示例程序呈交给史蒂夫

    评审时，他是在用自己的方式表达他的想法：相对于我的工作

    成果，我的个人想法同样重要。斯科特在非常谨慎地拓宽史蒂

    夫身边的小圈子，在我看来，他把谁带入这个圈子也是史蒂夫

    评价他的重要标准。这种直接接触首席执行官的层级限制并不

    会与其他大公司有太多的区别，但是在苹果，得到这种特权的

    方式与你在组织架构中的级别没有太大关系，而是与你做出更

    好的产品的能力息息相关。在我为iPhone原型机设计键盘的时

    代，虽然呈交给史蒂夫评审的示例程序是由我制作的，但我并

    没有资格参与“密室”评审，当时的我很难意识到虽然我写出

    来的程序对公司很重要，但我这个人是否参加评审并没有太大

    意义。

    斯科特同样扮演了一个示例程序守门人的角色，因为史蒂

    夫只会在已经存在足够优质成果的前提下推进工作。斯科特很

    清楚他不能给史蒂夫展示不入流的示例程序，并在声称自己的

    团队已经竭尽全力的情况下期望它们能得以侥幸通过。这样做

    除了能够激怒史蒂夫并使自己丧失除史蒂夫以外最有话语权的

    决策地位之外，别无益处。斯科特同样知道，他不能使用类似

    于在一群“老马”中安插一匹“千里马”的众星拱月的策略，寄希望于史蒂夫因自己挑选出了胜利者而满意。史蒂夫能够很

    轻易地看穿这些小把戏。

    在我和巴斯的共同努力之下，我的示例程序达到了标准。

    我们的示例程序是建立在三个要素的基础上的，这三个要素就

    是两种不同布局的键盘和一个能把两者结合起来的切换方式。

    在评审现场，我们发现我们的想法与史蒂夫的设想不谋而合。

    在这个示例演示中，史蒂夫看到了他喜欢的东西，但他认为这

    个示例程序中存在一些毫无必要的复杂元素，所以他将多余部

    分剔除。这种拆解并不常见，但在情理之中。

    就连史蒂夫据以得出结论的讨论环节都非常简略。请注意

    斯科特是如何介绍我的示例程序的：他用寥寥数语向史蒂夫讲

    述了接下来的工作内容，引导他把注意力转向我这里，并告诉

    他即将做演示的人是谁。接着，我又用最简单而必要的词语将史蒂夫的注意力吸引至需要他关注的地方。在此之后，史蒂夫

    认真地看了软件，问了我一个很精辟的问题，以确定键盘是否

    能变得更加简洁。

    对简洁的追求是有目的的。尽管史蒂夫已经是一个高科技

    公司的首席执行官，但他还是把自己当作普通的消费者，而消

    费者根本不会在意软件行业内部的诸多复杂细节。如今，人们

    已经被日常烦琐的事务困扰，他不希望苹果的软件给消费者增

    加额外的负担。

    想象一个场景，主角是每天忙于日常生活的母亲，这一

    天，她心中记挂着她16岁的儿子，她的儿子在寄宿高中上学，十分想家，却只能自己照顾自己。这位母亲奔跑在上班的路

    上，由于路上交通堵塞，她很有可能会迟到，她有一份报告要

    在下午提交，而在赶往下一场会议的路上，她需要再回复一封

    邮件。

    史蒂夫认为，如果她拥有一部没有装载那么多不实用的功

    能的手机，她的工作会做得很好。他相信将非必要的功能从手

    机里面清除将使人们容易学会使用手机，也会给手机的日常使

    用带来便利。他希望产品和软件能自己说话，因为在大多数情

    况下，没有人会站在一个首次体验软件的人的身后，指导他认

    真地辨别每一个功能的作用。当然，在苹果零售店里，每位员

    工都做好了随时回答问题的准备，但是，如果消费者在看到软

    件的时候就能立刻使用它，那不是更好吗？

    史蒂夫通过示例评审来判断每种功能是否符合这一基本使

    用标准。当他给我明确的反馈，要我把其中一种键盘从iPad示

    例程序中删除时，我觉得这带来的影响绝不仅限于更加简洁。

    这意味着我们可以取消巴斯设计的切换动画，去掉zoom键，清

    除所有关于在不同情境下会出现何种键盘的困惑。比如，iOS需

    要记住你在Notes应用里使用了“更大按键”键盘，在邮件应用

    中使用了“更多按键”键盘；这些键盘的选择应该被存储在哪

    些应用场景里，而不需要被存储在哪些场景里。这些问题变得

    更复杂且没有意义，因为它们没有简单的答案。史蒂夫认为，解决问题的最好方式就是避免提出这些问题。

    史蒂夫标志性的决断力渗透在苹果的日常工作中。他选择

    斯科特、格雷格、亨利和巴斯等人在他身边工作，部分原因是

    这些人无须长时间思考便可以给出合理的决定。当史蒂夫向我

    提问时，他在测试我的决断力以及判断我是否有能力将现有的

    示例程序改进得更优秀。会议室里面没有人插话，因为史蒂夫

    只看向我一个人，回答问题最有效率的方式就是由我来开口。

    我回答了，他随之结束了我的示例演示环节。

    一旦史蒂夫给出了他的决定，所有人就都知道再跟他争辩

    肯定吃力不讨好，这不是因为史蒂夫太固执而无法接受相反的

    观点，而是因为这样做无异于在现有的方案上增加复杂的东

    西，这几乎没有胜算。如果斯科特、亨利、格雷格和巴斯不清

    楚该在什么时候保持沉默，那么他们不可能坐在密室的沙发

    上。巴斯从未抱怨过自己设计的切换动画被删除，见证很多优

    秀的成果被砍掉也是他工作的一部分。示例评审这项工作流程也是由史蒂夫发起的，即使他不

    在，它也能成为我们在产品开发过程中使用的标准流程。就像

    在密室里一样，整个软件开发部门都尽可能地保证会议和团队

    的规模足够小，以保证工作效率，以及践行“以最小的成本做

    最多的事情”这条原则。史蒂夫对示例评审的频繁要求催生了

    不计其数的示例程序，每一个示例都有其演示者和决策者。所

    有示例程序的存在使得整个软件团队始终聚焦在开发最优秀的

    产品上。

    这些全都归功于史蒂夫。他在我离开前说出的那句“谢

    谢”向我表明，我的示例程序就是他想要的结果。这个会议是

    富有成效而且果断的，这种模式是值得被记住和效仿的。

    每每回想起这次iPad示例演示，我的嘴角都忍不住上扬，史蒂夫在会议中仅仅说了四句话，却教会了我太多道理。

    第2章 初入苹果

    苹果的上级主管们正在焦急地等待我们的消息——一份简

    介、一种进步的迹象，或者任何可以说明我们取得进展的消

    息。很久之后我才知道，斯科特当时已经开始怀疑我们是否能

    胜任了，很庆幸当时的我并不知道，因为在无法做出任何突破

    的一个月后，我自己已经感受到了巨大的压力。

    示例程序是我们在苹果工作的重要工具和手段。我们用它

    来发掘现有概念的潜力，探索新概念，展示进度，发起讨论以

    及驱动产品决策。在刚就职苹果公司的几个星期内，我被一个

    精妙绝伦的示例程序震惊了，这是我第一次见到这家公司是如

    何制作软件的。由此，我意识到并理解了示例程序可以在创意

    和技术工作中扮演多么重要的角色。鹦鹉螺没有吹响

    如果是那样，我的人生也将因此而变得不同。在加入苹果

    以前，我在一家名字叫Eazel的创业公司工作，我们的目标是开

    发一套简单易用的操作系统，这套系统可以作为苹果和微软系

    统之外另一个免费的选择。Eazel的核心团队成员是曾在20世纪

    80年代参与初代苹果计算机开发的程序员，包括苹果计算机的

    首位软件经理巴德·特里布尔以及软件奇才安迪·赫茨菲尔

    德。安迪的图像化用户界面代码，使得Mac计算机在当时以文本

    模式进行交互的主流计算机产品中脱颖而出。那些伙伴是我心

    目中的英雄，因此我决定加入其中与他们共事。他们设计的苹

    果计算机软件传达出的优雅和简洁是促使我成为一名程序员的

    主要动力。

    创办Eazel的想法来自安迪，他的创业念头则来自推广自由

    软件的动力——安迪与斯托尔曼一样，都是理想主义者。他通

    过开发文件和图标管理器使Linux成为微软系统和苹果系统真正

    意义上的竞争对手。安迪将他的项目命名为“鹦鹉螺”，它可

    以像文字处理器、制表软件一样帮助Eazel用户寻找文件、阅读

    邮件以及安排项目日程，也可以完成很多新奇的任务，比如记

    录一些数码照片等。Eazel公司将鹦鹉螺加入GNOME计划(一个

    致力于软件自由化的松散联盟，由个人和公司组成)，参与

    GNOME计划的成员将为我们正在开发的计算机系统提供其他软

    件。

    要成为GNOME计划的一部分，鹦鹉螺必须获得GPL的许可，这对于作为商业实体的Eazel来说具有很重要的影响。鹦鹉螺进

    入市场以后，用户可以使用，因此公司必须找到其他

    赚钱方式。不出意外的话，这些方式包括开发可以向用户收费

    的专业软件，比如一套原机云服务，它的功能包括为用户提供

    软件自动更新及在线文件储存等服务。这些服务将由Eazel数据

    中心提供，用户必须付费使用。这个想法是希望通过把免费的

    鹦鹉螺及其他免费软件打包来吸引人们为Eazel的特有功能付

    费。当时正处于互联网创业的高潮阶段，对Linux和自由软件的

    热情、充裕的风险投资基金以及创始人与初代苹果计算机的联

    系等因素融合在一起，构成了一幅美好的愿景，让我相信Eazel

    会成为下一个改变世界的伟大公司。

    我们确实有过那样的机会，但最终还是搞砸了。我们从未

    实现最初设定的任何一个崇高的目标。失败的原因有很多，但

    其中最大的败笔应该是我们没有将软件视为整体产品，而是将

    它们视为一组独立的项目，我们从未找到整合这些零散软件的

    方式。没有什么事情是一帆风顺的。我们的软件升级功能有很

    多故障，经常在软件升级的时候破坏程序。为鹦鹉螺与云服务

    建立连接的代码也完全不起作用。鹦鹉螺团队在与GNOME计划成

    员合作时也屡屡遇到问题——GNOME这种松散的组织结构和非营

    利导向，使得其成员不可能和我们一样，追求利润或者对合作

    保持高热度，这也导致我们几乎无法按照既定计划实现上线目

    标。种种挫折导致我们不断地将上线时间延后。在我进入公司几个月之后，这些问题变得越来越难以避

    免，为了让产品尽快成形，管理层开始向其他人求助。一个星

    期五的下午，我坐在公司小会议室里等着会见一位可能对我们

    有帮助的人。就在这个星期的前几天，我发现隔壁的小屋子里

    贴了一张写有“唐·莫尔顿”这个名字的纸，下周一这个

    叫“莫尔顿”的人即将成为鹦鹉螺项目的新主管，当晚我在公

    司月度聚会上第一次见到了唐。他很快发现他的名字被写错

    了。他从我身边经过，径直走向他的隔间，划掉纸上潦草的笔

    迹，重新写下“唐·梅尔顿”。

    唐是一位颇有街头信誉(street cred)的极客，因为他曾

    在公共广播公司播出的《代码奔腾》纪录片中露过几次面。这

    部纪录片叙述了浏览器之战的历史——在网络浏览器刚兴起之

    时，网景和微软两家公司争夺网络浏览器的市场控制权。20世

    纪90年代，越来越多的人使用计算机上网，微软公司开始担心

    计算机用户习惯于使用当下最流行的网景浏览器，从而使网景

    公司获得更高的利润和更大的市场影响力。微软试图通过把微

    软操作系统和自己研发的IE浏览器进行捆绑销售来阻挡网景的

    进攻，当时微软操作系统的市场占有率超过90%，微软寄希望于

    在计算机预装了浏览器的情况下，人们不会再向网景公司支付

    现金购买产品。

    突然间，网景如果想继续在网络浏览器这个自己一手创建

    的新领域站住脚，就必须使用全新的策略。作为反击，网景决

    定公开其浏览器的源代码，希望这种自由且可获取的代码能够

    成为所有基于互联网的应用程序约定俗成的标准。如果可行，这种方式可能会带来一些技术支持合约、咨询协议以及其他不

    直接绑定浏览器的赚钱的业务。

    这种代码开源的策略是受到自由软件运动的启发而产生

    的，但它并非理查德·斯托尔曼所认同的方式。斯托尔曼希望

    代码自由成为一种政治和社会福利，他理想中的软件应该是属

    于自由国度的，而对于网景来说，代码开源是一种挽救公司业

    绩下滑的手段。这就像把源代码变成了免费的啤酒，而真正的

    目的是通过举办啤酒狂欢节来赢利。

    历史证明这种方式无济于事，网景并没有以一家独立的公

    司的形式存活下来。网景彻底公开了浏览器的源代码，并为其

    冠以新的名字——Mozilla(摩斯拉浏览器)。Mozilla的成功

    得益于我们的新任经理唐的工作，在公开源代码前，他负责将

    所有的“脏话”从源代码中清除。

    网景必须在公开源代码之前将“脏话”从中清除这件事

    情，也给我们提供了一窥软件开发文化的窗口。即使是在我撰

    写本书的时候，大多数程序员也都是一群刚从大学校园里走出

    来的年轻人，为了满足不切实际的进度要求，他们需要通过喝

    咖啡来支撑长时间的编程工作，在21世纪初，这种情况可能有

    过之而无不及。当他们非常疲惫但时间紧迫时，他们的坏脾气

    开始爆发，不成熟的心智击败专业精神，技术层面或其他方面

    的纷争开始出现在软件中。使用驼峰式命名法时，程序员经常

    会将若干个单词集合成一个，一种具有代表性的不恰当的语言

    可能是这样编译的：cleanUpBobsSh_tStormHeIsAF__kingTurdBlossom;

    由于担心源代码一旦公开，这些糟糕的语言就可能损害软

    件的形象，网景公司的管理层发布了一项命令：代码中所有的

    脏话都必须被清除。净化代码是一项重大任务。唐被指定执行

    这一任务，他说自己是最适合这项工作的人，因为他实在太喜

    欢说脏话了。唐找到并清除了所有的脏话，但是开放代码并没

    有挽救网景在浏览器之战中的命运。网景输掉了这场战争。

    眼看网景就要失败了，唐开始寻找新的工作机会。当他加

    入Eazel时，软件开发进度的延迟并非我们面临的唯一难题。公

    司的现金流也开始变得紧张起来，Eazel没有产品可供出售，前

    一轮的融资资金也即将消耗殆尽。我们的高管忙于引入新的投

    资，最开始的一段时间，他们还会每隔几周给员工更新一下融

    资进度信息。后来他们变安静了，太安静了。

    让我们快进几个月：由于没有风险投资者开出支票，在

    Eazel推出鹦鹉螺1.0的当天，公司解雇了23的员工。唐和我属

    于仍被保留在公司内的一小群人，公司的高管一直在试图出售

    公司，我们又继续工作了3个月，直到他们出售公司的计划宣告

    失败。

    1. 代码中包含了一句脏话。——译者注

    苹果的浏览器替代计划

    唐和我都失业了，但是我们成了朋友，我们可没有在硅谷

    的高尔夫球场上瞎晃，而是一直在找工作。很快，我们听说苹

    果公司正在招聘。这家位于库比蒂诺的计算机公司为Eazel的前

    员工召开了专场招聘会，我记下了一些经理的电话号码准备跟

    进，永远比我更聪明的唐却有其他想法。之后的事情，就是时

    任苹果公司平台体验部门总监斯科特·福斯特尔对我进行的面

    试。在iPod和iPhone问世前，这个部门负责苹果计算机的用户

    界面，Finder、邮件等系统内置的应用程序，以及第三方开发

    者开发程序时使用的软件框架。

    当我到达苹果办公区参加面试时，斯科特已经坐在位于办

    公室一角的办公桌前了。当我走进办公室时，他转向我，身体

    向前倾，好像一个职业拳击手在等待下一回合的开始。我们面

    对面地互相做了自我介绍。由于我一直担心自己的面试能力，因此提前准备了一份道具——我最新编写的软件程序，一个可

    以在苹果全新系统Mac OS X中运行的拼图游戏。

    斯科特试用了我的程序，看起来他很喜欢。接着，关于软

    件的问题如雨点一般打在我身上，这就像年轻的拳王阿里在打

    一套左右组合拳，其速度和痛感令人难以招架。

    “你是如何设计算法来制作新拼图块儿的？”“你用了什么样的技术使得整个动画如此平滑流畅？”

    “你使用的是Cocoa框架、Carbon框架，还是混合框架？”

    整个面试过程节奏很快，我尽全力追赶他的节奏。后来我

    才知道，斯科特一贯如此。你一定要严加防守，否则他连珠炮

    一般的问题会让你惊慌失措。

    几天后，唐和我开车去了位于森尼韦尔的计算机文化书

    店，唐想要挑选一本书。我试着从他口中问出他在苹果面试的

    结果，以及他是否得到了关于我的面试反馈信息，但他如铜墙

    铁壁一般三缄其口。当离开书店回到车上后，唐递给我一本

    《JavaScript：权威指南(第三版)》，封面上的逼真的犀牛

    非常显眼。

    他说：“你觉得为苹果制作一个网络浏览器怎么样？你感

    兴趣吗？”

    我当然感兴趣。

    等等，Mac OS X不是已经有网络浏览器了吗？是的，的确

    有，但那是微软IE浏览器。早在4年前，苹果和微软做了一笔交

    易，IE被嵌入Mac系统。1997年8月，在波士顿召开的Macworld

    大会上，史蒂夫·乔布斯在公开演讲时宣布了这一决定，史蒂

    夫甚至邀请比尔·盖茨通过视频连接出现在大会屏幕上。就在

    那一天，盖茨承诺微软向苹果提供支持，在接下来的5年中，微

    软会为苹果计算机开发Office软件，向苹果投资1.5亿美元，同

    意苹果计算机安装IE浏览器并将其作为默认浏览器来使用。除

    了足足有20英尺高的盖茨影像如同“老大哥”一样笼罩在会场

    上这个令人尴尬的场景，这笔交易对于苹果来说是很划算的，这给当时正饱受唱衰舆论的苹果带来了一张重振市场信心的支

    持票。几个月前，《连线》杂志在封面上刊登了一张著名图

    片：彩色的“苹果”标志被带刺的铁丝环绕起来，在其下方有

    一个醒目的标题——祈祷。

    2001年夏天，苹果的基础更加坚实了，这得益于Mac OS X

    的完工、iMac的成功，以及即将在4个月后问世的iPod给人带来

    的希望。

    史蒂夫和斯科特迫切希望继续保持这种势头，认为互联网

    将成为未来计算机、通信以及商业的重要部分，希望苹果能在

    这一迅速崛起的技术领域占据一席之地。他们需要随时随地按

    照自己的意愿对公司互联网软件进行升级的自主性和灵活性，研发内部浏览器是这个战略的第一步。他们想把微软IE浏览器

    替换掉。驯服Mozilla

    从唐和我加入苹果的那一天起，这个浏览器替代计划就成

    了我们的工作。这项工作包含了两个阶段的目标：第一阶段，我们需要制作出一个网络浏览器的应用；第二阶段，我们要研

    发出一整套网络技术工具包，这套工具包可以让苹果第三方软

    件开发者更轻松地在自己的软件中添加网络功能，无论是下载

    文本、图片，还是呈现整个网络页面。简单地说，网络浏览器

    的确能够让用户在网上冲浪变得更加便利和简单。

    从程序员的角度来看，网络浏览器是极为复杂的。由于我

    从未做过类似的工作，为了让我尽快步入正轨，唐专门为我举

    办了一个“迷你新兵训练营”。在我们每天早上7点钟去店里买

    咖啡的途中，唐会为我全面介绍网络浏览器的每一个子系统：

    内容(文本和图像)、设计(字体、颜色和布局)、脚本(动

    态行为，例如在提交一个表格前对其进行检查)。他向我介绍

    了这些在技术领域内需要用到的已公布的标准：超文本标记语

    言(HTML)、层叠样式表(CSS)和Java脚本编程语言。此外，他还向我讲述了如何将这些软件组合起来以创造复杂的网页。

    在唐的引导下，我对这个领域的了解逐渐深入。我发现这

    项开发浏览器的任务对于仅有两个人的团队来说似乎是不可能

    完成的，尤其是在我得知网景浏览器制作团队规模非常大的时

    候。毫无疑问，微软IE浏览器的团队也一定是兵强马壮的。而

    我们的团队只有两人，我们怎么可能完成这项任务呢？

    唐让我不要担心，因为我们是站在巨人的肩膀上，不会像

    浏览器先驱网景公司那样从零开始。自由软件运动和浏览器之

    争使得网景公司公开了Mozilla浏览器的源代码，这意味着我们

    两人可以借用公开代码。我们可以就任何想要的细节去下载和

    评估软件，Mozilla的许可意味着我们可以在自己的项目上借用

    他们的代码。

    互联网上还有一些其他开源的网络浏览器项目，我们把这

    些项目当作调查对象，将其列入计划。此外，还有一些付费获

    取的软件可供评估。即使在尽职调查计划中有很多软件可供参

    考，Mozilla仍是我们首要的参考对象，主要是因为唐对其代码

    很熟悉。唐对我们的工作很有信心，认为我们可以胜任原本在

    网景需要很大的团队才能完成的工作。随着讨论的深入，我意

    识到唐对Mozilla有一种爱恨交织的感情。从好的方面来看，Mozilla在网络科技领域投入了巨大的资源，我们可以避免重复

    工作而直接利用其成果；但从另一方面来看，源代码数据库实

    在太大了，比我和唐在Eazel合作开发的软件不知道要大多少

    倍。由于听了唐对背景技术知识的介绍，我认识到了网络浏览

    器是一个大型编程项目的事实，我也接受了必须学习和掌握所

    有新代码这件事情。

    的确，当我下载了Mozilla之后，对源代码的第一感觉就是

    规模庞大——接近150万行。此前，我做过项目的规模连它的

    14都不到。若每页纸打印30行，一共需要5万张纸才能容得下

    全部代码。想象一下，这是在强迫你阅读大量复习资料，然后

    去参加一场可能从任何一行字里提取问题的考试。不管怎样，这就是我的工作，我最好还是赶紧行动起来，但我很快就遇到了障碍。Mozilla无法在Mac OS X上被构建，也

    就是说，虽然我拥有Mozilla浏览器的全部编程源代码，但当我

    尝试将这些代码变成可以在刚刚问世三个月的新系统上运行的

    应用程序时，我发现完全没有办法实现。显然，从来没有熟悉

    Mozilla的人这样尝试过。苹果计算机微不足道的市场占有率阻

    碍了我们。我在互联网上寻求帮助，但没有找到任何有用的东

    西，而且我们的项目是保密的，我不可能像普通程序员那样在

    在线信息板上发布问题，甚至也不能在苹果公司内部向其他同

    事求助。在经历了几天的失败后，我宣布自己遇到了无法逾越

    的障碍。

    我向唐汇报了自己毫无进展的现状，此时他正忙着与一些

    可能愿意合作的闭源供应商协商，希望他们许可苹果使用其浏

    览器代码。唐仍然倾向于使用Mozilla的开源代码解决方案，主

    要出于对价格的考虑，他认为比起其他付费软件动辄几百万美

    元的价格，免费软件更容易“卖给”管理层。

    与此同时，苹果的上级主管们正在焦急地等待我们的消息

    ——一份简介、一种进步的迹象，或者任何可以说明我们取得

    进展的消息。很久之后我才知道，斯科特当时已经开始怀疑我

    们是否能胜任了，很庆幸当时的我并不知道，因为在无法做出

    任何突破的一个月后，我自己已经感受到了巨大的压力。

    唐和我面面相觑，他说自己要出去度假一个星期，这是他

    在来苹果前就计划好的。他希望我能够在这一个星期里闭关，尽我最大的努力，在Mac OS X里面重建Mozilla。

    我开始全身心地投入。我做了非常详细的笔记，在代码上

    花了大量时间。当唐回到办公室后，我向他提交了一份名为

    《构建蜥蜴：使Mozilla在Mac OS X上运行的50个步骤》的文

    件。

    每一步都很重要。有些步骤看起来实在妙极了，尤其是在

    列表中间的一步：重建我的一个编程环境——C语言函数库。这

    一步就好像是在软件里面做大脑移植。它让构建蜥蜴看起来不

    那么像一份技术文件，更像一份低成本怪兽电影的恶魔脚本。

    好消息是，这些步骤在某种程度上起作用了，一步一步走

    下来，我可以制作出一个网络浏览器的图标，并能使之出现在

    桌面上；而坏消息是这个怪物一般的应用程序无法运行。用鼠

    标双击图片时，Mozilla会启动，但无论我如何尝试，浏览器都

    会立即崩溃，无法加载网页。我开始排查问题出在哪里，当我

    陷入几百万行代码中时，我感到了绝望。

    在进行市面上可见的浏览器评估时，我们同时也在招募其

    他人加入团队。我们被批准聘用更多的程序员，甚至在官方招

    聘信息发布之前就已经开始招聘了。唐认识一些在网景公司工

    作的有浏览器开发经验的人，我们也共同认识一些曾在Eazel工

    作但仍未敲定下一份工作的非常优秀的工程师，我们还很顺利

    地找到了一些内部推荐的候选人。同时，我们面临一个新挑

    战：说服那些有很多好机会的人接受一份我们暂时还不能透露

    具体内容的工作。唐的方法是通过眨眼向对方进行暗示，并告

    诉对方这是一份“重量级工作”。所有人都拒绝了我们。曾在

    网景工作过的那些人读懂了唐的眼神中隐含的意思，但没有人想要再做一个浏览器。最近在Mozilla身上栽的跟头让我理解他

    们为什么会做这样的选择。

    10×程序员

    就在尝试驯服Mozilla的过程中，我遇到了另外一位候选人

    ——理查德·威廉姆森，他一开口就告诉我他知道如何快速得

    到结果。他用一口已经被20多年在美国的生活经历冲淡了的不

    列颠口音的英语，向我讲述了他自己的经历。早在十几岁时，他就创办了自己的软件公司，后来，在斯沃斯莫尔学院读了几

    年书后，他决定休学，并在史蒂夫·乔布斯创办的软件公司

    NeXT工作了一年。在完成学业又回到NeXT后，他时常接到大人

    物直接安排的工作。比如，有一次史蒂夫派他到日本去与合作

    伙伴商谈为NeXT计算机设计一个扩展网卡的业务，他圆满完成

    了任务。

    理查德说出的每一个单词里都蕴藏着自信，他的经历看起

    来也支撑得起这份自信。他和我同龄，但当他创办自己的公司

    的时候，我还在每天玩电子游戏。在20岁出头的年纪，他就已

    经在日本为NeXT达成了一项跨国交易。那时我也在日本，但我

    只是一个刚拿到大学文凭，背着包教英语的长发青年。

    但是理查德是真的这么能干吗？还是说他只是一个纸上谈

    兵的人？我想先了解一些他的工作再做决定，我问了他一些在

    工作中遇到的技术性问题以及解决过程，每一次他都能很快找

    到解决方案。我观察到他会用特定的手势来强调自己的答案

    (见图2-2)，他的两只手的食指和小指伸出，两手指尖相对，两手之间保持与肩宽相等的距离。接着，他把两只手放在一起，随机摇动手臂。当两只手十指相扣放在胸前时，他接着摇

    晃手臂，但此时两只手臂是同步的，看起来就像发动机通过驱

    动轴向轮子传输动力一样。我每问一个问题，他都会重复一遍

    这一整套动作，好像对他来说，开发一款软件就像做驱动轴的

    动作一样简单。

    图2-2 理查德的特定手势面试后我去找唐，并告诉他我并不确定是否应该相信理查

    德的话。唐对我说，斯科特·福斯特尔的上司伯特兰·赛莱特

    在NeXT工作时曾与理查德共事，并且对他评价非常高。唐对理

    查德在面试中的表现有非常深刻的印象，因此希望他能加入团

    队。但他也尊重我的顾虑，建议我和理查德通个电话，再聊一

    次。(免费书享分更多搜索@雅书.)

    和面试时一样，在后续的电话中，理查德依然给出了信心

    满满的回答，我脑海中浮现出他用肩膀夹住耳边的手机以腾出

    两只手来做驱动轴动作的情景。挂掉电话后，我仍然不确定是

    否应该吸纳这位成员，但是我没有强有力的反对理由，所以我

    点头同意，理查德正式成为我们团队中的第三名成员。

    在我周而复始地对Mozilla进行构建、启动，又见证其崩溃

    的第二个星期，理查德开始了他在苹果的工作。在他工作的第

    一天，唐和我向他全面介绍了我们现在的工作进度、准备使用

    的开源策略、唐与外部公司谈判的情况、我们曾考虑过的作为

    备选的浏览器源代码、坚守Mozilla的决定、我的《构建蜥蜴：

    使Mozilla在Mac OS X上运行的50个步骤》文件以及依据这份文

    件制作的不停地因出状况而崩溃的浏览器。

    理查德问道：“你们在这个浏览器项目上工作了多

    久？”他的语调毫无波澜。

    唐回答：“6个星期。”

    理查德皱起眉头，似乎对我们几乎原地踏步的现状感到困

    惑，他又问了我们一系列关于技术细节方面的问题。他是在寻

    找我们没有注意到的蛛丝马迹吗？交谈逐渐深入，看起来理查

    德一直在保持风度，没有问出那个盘旋在他脑海里的问

    题：“你们这两个家伙到底做了些什么？”

    后来，在我和唐单独的聊天中，我们一致认为理查德只是

    不了解这个浏览器项目有多么困难而已，他的看法很快就会改

    变的。我们都喜欢这位新成员，很清楚他想把事情快速做起

    来，所以我们可以忽略一些略显粗鲁的言行。我们给了理查德

    大概一个星期的时间，让他处理好电脑和办公室设备等后勤工

    作，接下来，我们会向他更深入地介绍这个项目。

    没过多久，理查德就完全投入工作了。两天后，他叫我们

    来看一个示例程序。什么？一个示例程序？

    唐和我走入理查德没有窗户的办公室，这里漆黑一片，只

    有他的Mac计算机发出光亮。我们站在理查德身后，他点击鼠标

    并打开了一个网络浏览器——不是只有外壳，而是一个真正可

    以使用的浏览器。他接着加载网页，点击链接，然后返回，点

    击更多链接，加载更多网页，若无其事得像在进行一次非常普

    通的网上冲浪。我们到底在看什么？

    他解释道，我们正在看的是Konqueror，是几天前我们曾对

    他提起的开源浏览器之一。Konqueror由KDE社区开发，是一个

    与GNOME计划有着相似目标的编程社区。与Mac OS和Windows相类似，KDE是一个桌面操作系统，但它是基于Linux内核开发

    的。

    理查德说他下载了KDE系统，并给自己设定了一个简单的目

    标：在最短的时间内让代码在Mac计算机上运行起来，以便我们

    评估Konqueror网络浏览器的潜力。由于KDE是基于Linux内核开

    发的，无法在Mac OS X上运行，于是，理查德做了一个夹层，这是一个软件翻译夹层，其作用在于误导Konqueror，让它认为

    自己正在Linux操作系统中运行，接着再骗过Mac计算机，使其

    以为当前运行的浏览器是为自己量身定做的。这里要强调一

    下：写这样一个夹层是极其困难的。由于我们先入为主地认为

    这项任务是无法逾越的障碍，所以当看到理查德仅用两天时间

    就完成夹层时，我们相信了他的自信绝非自吹自擂。我们正在

    看的是一个天才的杰作。

    理查德似乎感受到了我们的惊讶，他告诉我们能够使示例

    程序运行的两个快捷方式。首先，他使用了Linux图形系统，即

    X Windows图形用户接口，而非源于苹果的核心图形系统；其

    次，他运行了整个KDE系统，而不仅仅是Konqueror浏览器。尽

    管对于有些人来说，这些东西听起来莫名其妙，但我和唐却非

    常清楚，理查德进一步介绍了他的工作，唐和我开始研究这些

    快捷方法是如何让Konqueror的代码快速运行起来的。

    理查德并不在意X Windows用户接口似乎与Mac计算机屏幕

    上方的菜单栏不那么匹配，也不在意这个系统无法提供高像素

    级的字体渲染，更不在意整个KDE系统其实包含了许多与网络浏

    览器不相关的软件。理查德很清楚这些技术细节需要在未来一

    段时间内解决，在他回到电脑前继续进行网页浏览时，盘旋在

    观看示例程序的两位观众心头的不安感也随着时间逐渐消失。

    正如理查德之前所告知的那样，仅仅需要一个夹层、两个

    快捷方式以及两天时间就能够做出一个可以使用的浏览器示例

    程序。理查德快速形成的成果充分体现了Konqueror这座矿脉的

    潜力，这是一个我们可以探索、开采以及利用的宝藏。

    我和唐已经为网络浏览器项目忙碌了6个星期，几乎毫无进

    展，我们仍然没有写出可以演示的程序代码，也没有做出任何

    计划。在很短的时间内，理查德下载了一个Linux网络浏览器，并略施小计诱导Konqueror在Mac计算机上运行。他的示例浏览

    器能够打开、加载网页，不但没有崩溃，反而运行得非常顺

    畅。我和唐十分惊讶。如果理查德再配上他标志性的驱动轴手

    势，那么我可能会晕倒。

    理查德是怎么做到的？唐和我都是经验丰富的工程师，唐

    在网景公司从事了很多年的网络浏览器开发工作，但理查德的

    示例程序让我们猝不及防。

    怎样才能更好地理解他的成就，并衡量、量化它呢？我们

    必须用硅谷传说中的“10×程序员”来定义理查德。10×程序

    员说的就是像他这样的以一顶十的具有超高效率的软件天才。

    这样的人真的存在吗？毕竟这种普通和卓越之间的巨大差

    距在日常生活中并不常见。如果你每分钟打50个字，坐在同一

    家咖啡店里面打字的另一位仁兄不可能每分钟打500字。真实的物理世界里有绝对限制，就人体生理机能而言，即便是精英也

    不会超过生理限制。即使是奥运短跑冠军，也不可能在1秒钟以

    内完成100米赛跑。

    这类限制在技术开发领域依然有效吗？在1975年出版的软

    件工程领域的经典《人月神话》中，作者小弗雷德里克·P.布

    鲁克斯认为绝对限制依然有效。20世纪60年代，布鲁克斯曾在

    IBM(国际商业机器公司)负责管理OS360主机操作系统项目，他在这段经历中积累了很多经验并分享了出来：“当一个任务

    由于严格的时序约束而无法被分割时，只增加人力对加快整体

    进度没有任何帮助。就像无论有多少妇女参与，从怀孕到孩子

    出生都需要花费10个月时间一样。”

    在软件开发过程中，这些限制是必然且一直存在的吗？在

    布鲁克斯谈到的大型项目中，成百上千的小团队共同完成相互

    关联的计划，遵从共同的时间表，这种团队规模的确限制了工

    作的速度，过多的联络和流程协调限制了每个个体能力的发

    挥，即便是天才也难有用武之地。

    但是，在软件开发的早期阶段，摆脱这种限制是非常有可

    能的，尤其是在团队规模很小而且仍在寻找灵感的时候。这就

    是理查德加入苹果时，我们所处的情境。我们仍在探索能启动

    网络浏览器开发工作的概念框架，而现在，理查德已经向我们

    展示了这一成果。不仅如此，他还证明了在软件开发的早期阶

    段，10倍的效率差距绝不是上限。实际上，理查德仅两个工作

    日的成果就远远超出我和唐在先前合计12个星期所做的全部工

    作。这差不多已经是30倍的差距了。

    理查德·斯托尔曼

    “水晶球”示例程序诞生于21世纪初期科技浪潮的背景之

    下，当时互联网创业热潮如日中天，微软是计算机领域无可争

    议的领导者，网景公司的网络浏览器代表了当时最新的技术，而苹果则前景黯淡。

    那时，很多硅谷的软件公司开始尝试推出自由软件，试图

    通过开发不向消费者收费的软件来获利。这种看起来不合逻辑

    的公司战略来源于理查德·斯托尔曼的思想，理查德·斯托尔

    曼是一位颇有声望的程序员和科技爱好者。他认为所有软件都

    应当是自由的。斯托尔曼抨击微软、苹果等公司，它们向消费

    者收取软件费用，却把源代码当作商业秘密，不对外界开放。

    在斯托尔曼与众不同的信仰体系里，计算机代码和利益动机混

    合在一起酿成毒酒，这杯毒酒迫使科技公司雇用了许多从事编

    程工作的知识分子，把软件开发彻底变成了一个“零和游

    戏”，而这些高智商的人本应致力于科技的进步，这样一来，损害了人类整体的利益。如果你不是程序员，自由软件听起来

    就像20世纪60年代的嬉皮士理想主义。

    但是我是一名程序员，对于我来说，自由软件更像有史以

    来最美好的糖果商店。假如我是一名想要开发照片分享应用的

    创业者，或者是一名正在研究人工智能算法的计算机科学家，或者是一位尝试提升数据中心计算机使用效率的系统管理员，我知道自己可以在网上找到业已存在的代码，并能根据我的目的来进行相应的更改。自由软件使通用问题的解决变得更容

    易，在上述任意一个场景中，只要同意其他人使用我基于现有

    自由软件撰写的新代码，我就可以使用这些自由软件。斯托尔

    曼把自己比作站在自由软件糖果店柜台后面的人(见图2-1)，在那里他保证没有金钱交易，但是软件源代码会不断地转手。

    斯托尔曼于1983年成立了GNU计划以呼吁软件自由化，而且

    他起草了GPL(《通用公共许可协议》)，用来推进该计划的实

    施。斯托尔曼将GPL称为“公共版权”，这是一个故意与“版

    权”相抗衡的称谓，与限制使用者的权限不同，GPL拓宽了使用

    者的权限，保证每个人都能几乎无成本地获取软件的源代码，人们可以研究、修改，将它们用于新项目架构的搭建。这听起

    来是完全自由的，但是GPL有特殊的要求。如果你在GPL框架中

    的软件源代码的基础上开发了新软件，那么这个新软件也必须

    接受GPL的约束。斯托尔曼希望通过这个体系建立良性循环，不

    管你是富人还是穷人，新手还是天才，程序员还是终端用户，都能因代码编写者在互相借鉴的基础上不断优化软件产品而受

    益。

    图2-1 站在自由软件糖果店柜台后面的理查德·斯托尔曼

    如果不在软件行业工作，你可能从未听过理查德·斯托尔

    曼这个举足轻重的人物。几十年来，自由软件已经在整个高科

    技领域普及。斯托尔曼的GPL促进了Linux操作系统的开发和问

    世，如今Linux已成为在安卓智能手机，谷歌、亚马逊、推特及脸书的数据中心，以及众多主流网络服务商平台中运行的核心

    软件。没有斯托尔曼的长期努力和自由软件的兴起，我们所知

    道的互联网可能根本无法出现，网络搜索引擎、流媒体音乐、YouTube、维基百科、聊天软件、社交网络、智能手机可能也不

    会出现。整个世界都将是另一番景象。

    示例程序法

    怎么解释这种巨大差异呢？表面来看，这要归功于理查德

    的编程的成果——他做的软件夹层；或者，他利用Konqueror浏

    览器做文章似乎与我在Mozilla上下功夫一样，也许他只是一个

    比我更优秀的程序员。如果没有他的编程能力，就没有接下来

    的故事了。

    这种解释未免显得太单薄。理查德是在灵感萌发、直觉判

    断、推理和预测等一系列工作的基础上决定把夹层作为链条的

    最后一环的。他的夹层是整体计划的最终结果。为了把我的意

    思表达清楚，我们接下来盘点一下理查德在刚到苹果的几天内

    所做的工作。

    首先，他浏览了我们在此之前所做的所有关于浏览器的研

    究，然后他迅速地判断出他需要抛弃对Mozilla的研究，因为这

    样下去大概率不会带来想要的结果。他勇敢地走出了这一步，充分显示了他的自信，同时也没有向在这一领域耕耘已久的上

    级表现出谦卑和顺从的态度。接下来，理查德决定在最短时间

    内得到结果。他下载了一个可能有潜力的开源项目——来自KDE

    社区的Konqueror浏览器的代码，这个浏览器可能会成为我们长

    期努力的基础。为了使这个代码在Mac计算机上运行，他决定在

    最短时间内做一个可以模拟真实浏览器的示例程序。他确定了

    三项功能——加载网页、点击链接、返回上一页。他列出的这

    几个功能足够说明了概念的可行性。随后，他制作了快捷方式，这些简化了的选项定义了一套不需要达成的目标——完美

    的字体渲染功能被废除，这是为了与Mac计算机本身的图形处理

    系统相匹配，也是为了尽量少地使用KDE的源代码。他认为，这

    些快捷方式虽然非常醒目，但不会分散使用者在浏览网页时的

    注意力。理查德着手将这些线索串联起来，集成在一个示例程

    序里，向我们展示了Konqueror的潜力。最终，他完成了技术细

    节，开发出了软件夹层，这是实现计划的关键要素。他的思考

    过程使得其自身的技术能力得以更大程度地施展。

    与之相反，唐和我都寄希望于Mozilla能担起重任。我甚至

    没有深入思考，就一直尝试在Mac计算机里运行Mozilla庞大的

    开源代码。我没有设置任何类似的计划、目标、不需要达成的

    目标、紧凑的时间表、技术路径。

    最重要的是，这种思维方式上的差异导致了截然不同的结

    局。这也绝不是因为唐和我陷入了一个暂时的困境。我们初来

    苹果的做事方式还是像之前在Eazel一样，我们不可能做出优秀

    的桌面—云集成服务样机的原因就在于，直到公司耗尽现金，遣散了大多数员工的那一天为止，我们都未曾尝试从整体上集

    成我们的软件。在Eazel工作的那段岁月里，我们从未想过使用

    类似理查德展示的这种快速完成计划的方法。

    如果唐和我沿袭旧有的思路继续在苹果做事情，我们真的

    不知道哪一天才能做出示例程序。在我们职业生涯的那个阶

    段，我们根本不知道如何开启一个大项目，如何踏上寻找成功

    的征途。

    理查德对这一切都很清楚。他的示例程序就是解决问题的

    关键。他向我们证明了Konqueror浏览器可以在Mac计算机上使

    用。他用简单的方式展现了这个代码的潜力。的确，是理查德

    的软件夹层使其突破成为可能，但想想看，他围绕自己的计划

    所构建的概念框架，以及为了做出浏览器示例程序突破的重重

    困难，直到最后才用一个小小的自定义程序片段——夹层——

    使问题得到圆满解决。这种逐步累积起来的效应最终会创造出

    一个真实浏览器的幻影，尽管展现出来的仅仅是不完整的一部

    分。

    这种方式起作用了。唐与我看到示例程序，就好像理查德

    把我们叫进办公室，办公桌上放置着一个水晶球，他挥手召唤

    我们走近，并向我们展示网络浏览器未来的模样，为我们指明

    了将梦想变为现实的路径。

    理查德的示例程序也涉及一些常识，我会借助另一个有着

    悠久历史并且擅长利用简化选择和割角法的行业来介绍这些常

    识。与理查德在示例程序中使用的技巧一样，这些常识能让我

    们看到实际上并不存在的东西。

    以好莱坞的外景场地为例，电影制片厂需要用到一些半永

    久性的户外场所，这里的人行道、小巷以及主要街道都是拍摄

    电影所需要的场景。尤其是在特技拍摄和计算机辅助特效技术

    广泛应用以前，外景地的作用是至关重要的。即使预算有限，一个外景地也可以改变一个场景。为了给观影者呈现出令人信

    服的景象，我们必须在荧屏上展现一定数量的真实景观。我最喜欢的外景之一来自《雨中曲》，这部音乐电影由米

    高梅电影公司出品，拍摄于1952年，由吉恩·凯利和黛比·雷

    诺斯主演。以其中最著名的舞蹈片段为例，吉恩·凯利在黛比

    ·雷诺斯的公寓门口与她吻别道晚安后，兴高采烈地轻踏、跳

    跃、溅起水花，在倾盆大雨中旋转(见图2-3)。这一场景设置

    在好莱坞的一个外景地，它看起来像一个城市的街道。就在凯

    利跳着舞从建筑物的屋顶上往下冲时，他跳过了La Valle女帽

    店。这家店看起来很诱人，陈列着几顶时髦的女帽。当然，这

    不是一家真正的商店。店面可能是一间后面什么都没有的铺着

    鹅卵石的公寓，也可能是一间工作室。穿过商店的门，也许是

    米高梅的簿记员或办事员的办公室。我们不在乎。我们被歌曲

    和舞蹈迷住了。把这个假帽子店和一排早些时候看到的另一件

    道具——凯利跳上去的人行道边上的那根灯柱——进行比较，与帽子店不同的是，灯柱道具必须是真实的，或者至少要真实

    到能够支撑演员的体重。外景地的其他灯柱也建得同样好吗？

    我们不知道，但我们不在乎；它们也许建得同样好，也许建得

    没那么好，但是布景设计师需要确保一个特定的灯柱足够坚

    固，让电影中的主角能够跳上去。它必须建得很好，因为舞蹈

    编排需要它。

    图2-3 吉恩·凯利在雨中跳舞

    同样，尽管示例程序并不是产品本身，但它必须要有足够

    的说服力，让人们开始探索某种思路，向做成产品的方向迈进

    一步。就像电影一样，示例程序应该经过特别精心的设计，需要被展示的和需要被排除的都必须非常明确。这些事情虽然不

    是做一个示例程序的主要着眼点，但也需要合理设置，在合适

    的细节级别上被展示出来，这样它才可以服务整体而不会让人

    转移视线。

    理查德将这套理论付诸实践。他选择了可能会在正式产品

    中应用的Konqueror开源浏览器作为工作的基础，确保这套示例

    程序可以加载网页、点击链接以及返回上一页(这几项都是浏

    览器的核心功能)。字体渲染并不符合苹果的标准，有些字符

    不平滑、参差不齐，但是文本已足够清晰，所以理查德没有在

    排版上浪费太多时间。他完全不会在不相关的细节上耗费精

    力，也没有制作键盘快捷键或者设计一个漂亮的苹果图标。他

    将重要的、可用的以及可忽略的功能认真地进行排序，以保证

    最大程度的影响力，尽量减少干扰，并严格按照自己设置的时

    间表完成工作。

    在理查德向我展示这个浏览器示例程序之后的若干年，我

    一直在效仿他的这套工作方法。当我做一个示例程序时，我会

    考虑目标受众，并在此基础上决定这个示例程序需要包含哪些

    功能。我用想象中的一支粗马克笔围绕所有重要细节画一个

    圈，就像电影场景里面的灯柱一样，我尽最大努力地保证它们

    的真实度。我把剩下的不那么重要的细节留在了圈外，这些细

    节最终还是会出现在成品中，但现在不急于展现它们。我尽可

    能地在它们身上少分配一点儿注意力。就像那间帽子商店的内

    部构造一样，如果可以，我会把所有不重要的东西都从示例程

    序中清除。在两者交汇的地方，我会非常小心。有些元素刚好

    落在粗线上，这是需要关注的细节，因为它们有助于构建场

    景，让受众打消疑虑。比如，一个应用程序的用户界面仍处于

    开发早期，我可能会将另外一个应用程序的用户界面放在我的

    示例程序中，而不会花时间做一个完全可用的用户界面，因为

    此时用户界面是次要的。这就像在商店橱窗里放置几个道具帽

    子，我希望观看示例程序的人认为他们看到了真实的效果，尽

    管这些场景未必是真实的。我知道示例程序并非真正的产品，我的同事们也清楚这一点，但是在产品开发过程中，呈现出我

    们试图实现的效果是非常重要的，因为这样一来，我的同事们

    就会将示例程序当作真正的产品来给予反馈。

    这种在整个开发过程中建立“分镜头剧本”的尝试，体现

    了电影拍摄外景地与示例程序的一大共同特征，它们都是宏大

    故事中的元素。每一个元素都在推动故事的发展。吉恩·凯利

    在雨中的舞蹈和歌唱表现了初吻的喜悦，在电影里的那个时

    刻，男女主角把他们坠入爱河的信息传达给了观众。这是好莱

    坞电影的“魔法”时刻。理查德的示例程序让我们看到了

    Konqueror开源代码的潜力，我们认为这极有可能是我们一直以

    来苦苦寻求的答案。这是硅谷软件“魔法”的巅峰时刻。

    久而久之，唐和我都理解并吸收了理查德展现给我们的示

    例程序。我们寻找能够加快进度的各种方法，排查任何可能会

    因缺乏潜力而拖延项目的因素，选择捷径以避免不必要的劳

    动，将精力集中在关键之处，以尽快接近最终目标，将我们自

    己最艰辛的努力转化为最强大的影响力，将灵感、决断力、技

    术融为一体，完成一个又一个示例程序。我们学到的这些知识都来自理查德，他改变了我们工作的

    方式。

    第3章 第一次“尤里卡时刻”

    我冲进走廊去找唐。当我们回来时，我关闭浏览器，然后

    重新加载雅虎主页。在同样的停顿期间，我们屏住呼吸……接

    着我们看到了同样的黑色长方形。我们的浏览器终于开始做点

    儿什么了!移植策略

    在理查德向我们演示了他的示例程序后，我们仍然对代码

    开源的Konqueror浏览器所知甚少，但是当务之急是尽快确认它

    是否真的像看起来的那般美好。唐建议我们仔细研究它的源代

    码，即对软件的编写进行说明的代码主体，它决定了软件的功

    能框架。唐特别明确地希望我们将Konqueror浏览器与KDE的其

    他软件隔离开来——必须抛弃理查德在示例程序里面所走的捷

    径。他还需要我们评估Konqueror浏览器的复杂程度，所以我们

    得数一数它的源代码究竟有多少行。数数这个看似简单的行为

    可以让我们把Konqueror与Mozilla做个对比，也可以让我们感

    受到把理查德的示例程序变成真正的产品到底有多难。

    唐把数代码的工作交给了我，他可能是想让我投身于理查

    德那令人印象深刻的编程成果中。如果真是这样，那么不得不

    说他的方法奏效了。在示例程序演示的第二天早上，我6点钟就

    来到了办公室，比平时提前了足足一个小时。在我的办公桌

    上，Mac计算机旁边，有一个台式机。我计划用这个台式机下载

    所有的KDE源代码。在下载完成后，我会浏览所有的代码，然后

    运行一些测试，将Konqueror的源代码从整个系统中分离出来。

    在等待安装程序运行的过程中，我看着面前的两台计算机

    ——一台装载着Linux系统的计算机，一台Mac计算机。两台计

    算机在我的桌面上仅有几英尺的距离，但两者搭载的软件却有

    很大差别。尽管Linux和Mac OS X都可以追溯到由贝尔实验室在

    1969年推出的Unix操作系统，但二者早已沿着各自的路径分道

    扬镳，渐行渐远。久而久之，Linux和Mac好像变成了使用同一

    种语言的两个独立国家。只不过在Linux中用“lorry”来表

    示“卡车”，而在Mac中用“truck”来表示“卡车”。在终端

    用户使用的应用程序层面，二者的兼容性很差，但对于程序员

    来说，在底层算法层面，二者的相似度是比较高的。它们保留

    了一些相同的技术语法和语义，都可以运行用C++语言编写的程

    序，而Konqueror的开发者正是用C++语言编写了这套浏览器。

    尽管如此，这两个系统还是会使用不同的编程词汇和习语在

    C++中进行编程，尤其是在图像用户界面上。结果，我们并不能

    简单地把一个系统上的源代码复制过来在另一个系统上使用。

    我们如果要把Konqueror作为浏览器项目的基础，就必须修正

    Konqueror在Linux系统下运行的源代码中的术语和技术差异，并用可靠的软件工程替换理查德的夹层。把为某特定操作系统

    编写的代码改编成适用于另一个操作系统的代码，对于程序员

    来说是很常见的任务，这项任务可以用一个专门的词——“移

    植”来形容。由于我们只能从看似为Mac计算机量身定做的源代

    码出发——而我们都知道并非如此——开发出一个符合苹果标

    准的网络浏览器，因此程序员的工作必须要做得非常漂亮。

    从KDE中分离出网络浏览器代码并没有花费我太长时间。这

    个软件有非常整洁的结构，Konqueror基本上藏身于KHTML和KJS

    两个目录下。

    在将它们分离出来后，我命令计算机计算两个目录下的代

    码行数。这会让我们更好地估计“移植”工程的整体工作量，行数越少则工作量越少。看到结果后，我开心地笑了，当我把

    结果告诉唐和理查德后，他们也笑了。Konqueror的代码仅有12

    万行，还不到Mozilla浏览器的规模的110。起初，我们还没有

    办法相信两个功能相近的浏览器在代码数量上会有如此大的差

    异。

    唐对此进行了解释。Mozilla项目领导团队的初衷是将软件

    变成像乐高一样可以随意组装的构件。但是，这项计划需要大

    量额外的样板代码——程序员不得不使用复用系统做一些类似

    于填写大量表格的事情来注册新代码。这导致他们的浏览器臃

    肿不堪。我们已经清楚两种不同的工程决策导致Mozilla和

    Konqueror在代码量上的比例为10∶1，很显然，组装构件的概

    念完全失去了优势。Mozilla臃肿、笨拙，而且使用起来非常麻

    烦。

    Konqueror团队则采取了相反的策略，他们的代码是精练而

    灵活的，他们更崇尚简洁。他们的软件风格更像海明威，而

    Mozilla则像出自福克纳之手。

    Konqueror的源代码更简洁，理查德已经利用Konqueror做

    出了很棒的示例程序，而且我对源代码行数的分析仅花了几个

    小时。尽管这一切并不意味着我们的“移植”工作一定很轻

    松，但是我们对成功来得如此之快感到非常喜悦。

    这给我们接下来的汇报工作带来了信心。唐说他将与理查

    德一起向软件工程管理链的上级演示这个示例程序，希望得到

    斯科特·福斯特尔、他的直接上级伯特兰·赛莱特以及伯特兰

    的上级阿瓦德斯·特凡尼安的支持，让他们同意我们把

    Konqueror作为网络浏览器项目的基础。

    几天后，这些高管正如我们期待的那样被震惊了。理查德

    的示例程序如此清晰且有说服力，我们无须多费口舌就让管理

    层确信浏览器项目已经步入正轨。

    经过他们的许可，下一步的工作就是制订把Konqueror的12

    万行代码向Mac系统“移植”的策略。要想理解我们即将开展的

    工作，需要对软件开发专业术语有一定的了解。代码与菜谱

    当我需要计算机执行一项工作时，我用一种编程语言，比

    如KDE开发者编写Konqueror浏览器时使用的C++语言，在计算机

    上输出明确的指令。

    如果你对程序员用来写代码的符号不太了解，那么这种描

    述听起来可能会有点儿不知所云，但是抛开这些学术名词，计

    算机程序就像菜谱一样，两者都为完成某项任务提供了指引。

    不同之处在于，厨师们写的菜谱是供人们阅读的，而程序员不

    能用同样的方法给计算机写代码，因为计算机本身并不理解编

    程语言。计算机只能识别二进制语言中的数字0和1，所以，要

    让计算机执行我命令的工作，我必须把C++代码用编辑器转换成

    计算机可以识别的二进制的形式。这种将人类语言转换成机读

    语言的过程就叫编译或构建，这个翻译的过程也解释了为什么

    用编程语言编写的一行行代码叫作源代码。通过编译器，它们

    可以转换成计算机可以执行的二进制代码。

    图像

    类似网络浏览器这种全功能程序，需要的源代码的数量是

    巨大的，即使像Konqueror这种相对简洁的程序，其代码也超过

    10万行，程序员要把所有代码分割成独立的源代码文件。这样

    做可以让程序员分别负责独立的子任务。比如，在网络浏览器

    这个项目中，负责处理网络地址(URLs)的代码可能被集中在

    一个源代码文件中，而另一个相对复杂的相关领域，比如利用

    网络地址从互联网上下载数据的代码可能会被分散在很多源代

    码文件中。厨师们会将菜谱分割成若干独立的部分。比如，班尼迪克

    蛋的配方会包含一个荷兰酱的子菜单，此外还有关于如何煮

    蛋、煎加拿大培根，以及烤英式松饼的子菜单。但是菜谱作者

    可能不会在班尼迪克蛋的配方中把荷兰酱的制作方法介绍得很

    详细，尤其是当荷兰酱在菜谱中随处可见的时候，比如，可能

    在制作芦笋的部分就已经介绍过荷兰酱了。一个综合性的菜谱

    很可能只会介绍一次荷兰酱的制作方法，然后在其他需要的地

    方做一个索引，比如，“荷兰酱的制作方法见第123页”。

    程序员也使用同样的方法。在编写一个关于从网页上下载

    数据的源代码文件时，我会用到处理URLs的代码。我不会把整

    个代码复制到我需要的所有地方，而是会用一个包含指令来引

    用URLs源代码文件，这与班尼迪克蛋中的荷兰酱制作方法的前

    后参照有异曲同工之妙。软件中存在包含指令的原因与菜谱中

    存在交叉引用的原因是一样的。有了这类指令，程序员在每一

    个特定的任务中只需要写一份详细的指令就可以了。

    这个系统并不完美，因为这种相互参照的结构会增加出错

    的概率。比如，我正在做一份班尼迪克蛋，按照索引前往第123页研究如何制作荷兰酱，但当我翻到第132页时，我却找不到制

    作荷兰酱的方法。

    在编程过程中，这类错误比比皆是。人是容易犯错误的，而计算机是铁面无私的。编写程序时很多事情都会出错，比如

    使用了错误的编程语法(就像在菜谱中出现拼写错误一样)，或者在包含指令下参照了错误的文件(就像翻到了菜谱里错误

    的页码而无法找到荷兰酱的做法一样)。更重要的是，如果你

    的表达不够准确，那么编译器很可能无法正确理解你的意思。

    每当我犯了上面任何一个编辑错误，编译器都会向我发送

    一个出错信息提示，信息内容简单而精确：“期望的表达式，第3行，第5列。”这种未被满足的期望可能是打字错误或者简

    单的逻辑错误，这类报错就像主厨在一个忙碌的餐厅里巡察

    时，看到初级厨师在准备班尼迪克蛋时提醒他“荷兰酱太厚

    了”。这两种信息都起了报错的作用，它们尽管没有提供改正

    错误的方法，但依然非常重要。

    当我下厨时，即使我每一次都一字不漏地参考一本优秀的

    菜谱，端上餐桌的菜品可能也不尽相同。有时可能味道不错，有时可能需要多加点儿盐，有时可能因为厨艺太差而没有达到

    期望。在计算机的世界里，我即便修正了编译器提示的所有错

    误并成功地让程序构建起来，最终也很难让这个程序在第一次

    构建完成后就按照我们计划中的方式运行，并输出预定的结

    果。代码可以被准确无误地编译，但我们可能无法在计算机上

    得到想要的结果。网络浏览器这类复杂程序在运行过程中可能

    会发生无数种行为错误：文本在错误的位置上被渲染，图片由

    于图形错误被截掉一部分，一个按键或者链接对点击无响应。

    网络浏览器程序也可能由于一个严重的编程错误而彻底崩溃，这有点儿类似于你在下厨时把一碗配料洒到地上。在代码被顺

    利编译之后但尚未按照预定目的运行并给出满意的程序之前，持续的修订和改进就是不断重试的过程。就像你尝试在厨房里

    完善食谱一样，要让一个程序构建起来并按照预定计划运行需

    要大量的重试——重写源代码以改进编程指令、修正编译器错

    误信息、重建代码、运行程序或应用、排除故障，然后回到源

    代码进行编辑，并不断地重复这一过程，很快你将见证这一

    切。修正、重启、报错……

    在得到管理层的支持后，理查德和我立刻来到唐的办公

    室，一起讨论下一步的“移植”策略。

    首先，我们需要回到理查德的示例程序上，完成功能的简

    化。要做到这一点，我们需要将Konqueror浏览器相关功能的源

    代码文件复制到Mac计算机中，并用这些代码构建软件。在此之

    后，我们可以开始测试和调试程序，使得被构建的浏览器看起

    来像本来就属于Mac软件系统一样。

    别忘了，由于Konqueror是自由软件，我们必须遵从斯托尔

    曼先生的要求，授权原开发者获取源代码。我们管理层很愿意

    将部分软件开源，但是保证大多数代码闭源私有也是非常有必

    要的。原因很简单，Mac OS X是苹果的重要收入来源。在其后

    的iPhone时代，苹果免费为使用者升级软件，但在我们开发浏

    览器的时候，公司以每台计算机129美元的价格在美国境内出售

    Mac操作系统。当我们制订网络浏览器策略时，高管们给我们的

    指令可不是把浏览器当作“完全自由开源”的产品或“啤酒节

    的免费啤酒”这种吸引客户付费的产品来制作的，浏览器更应

    该是闭源而且能给公司带来收入的产品。

    唐、理查德和我必须在这个框架下工作，正当我们敲

    定“移植”策略中开源和闭源的部分时，一个有趣的化学反应

    开始在我们三个人之间发生。

    唐喜欢不停地钻研自由软件许可的各种细节。当他在网景

    和Eazel工作时，他就是这个话题的专家，喜欢翻来覆去地讨论

    这些许可的优势、弊端以及不同许可的各项条款。他对阐述

    LGPL(宽通用公共许可证)的各类分支有着显而易见的浓厚兴

    趣，LGPL是给Konqueror源代码授权的自由软件许可。这些条款

    要求，我们只要在Mac计算机的“菜谱”中任何一个独立章节内

    保留了Konqueror(哪怕只是用它的代码做了交叉引用，或者为

    了使它在Mac计算机上“味道更好”而对Konqueror这道菜的配

    方做出修改)，就必须遵守斯托尔曼的自由软件许可的规定。

    理查德看起来完全不在意自由软件，用翻白眼和叹息来回

    应唐的一次次关于软件许可的超长演说。

    我徘徊在他们二者之间。我认为自由软件许可很重要，尊

    重前人的工作当然是理所应当的；更何况，如果不遵守

    Konqueror的许可条款，那么我们可能会让苹果公司惹上官司。

    我不想陷入必须遵从协议的困扰，但我认为花点儿时间认真思

    考以扫清技术和法律上的障碍是很有必要的。

    我们为了获得许可而采取的不同方式，让这个软件策略看

    起来像由三个书呆子重演的《金发女孩和三只熊》。幸运的

    是，“达成一致”并没有想象中那么困难，几个小时后，我们

    敲定了计划。为了解释清楚这个计划，我们需要再次用菜谱做

    比喻。

    把建成Linux和Mac操作系统的数百万行代码，想象成由多

    个独立作者撰写的综合菜谱。在这些菜谱中，一定会有重复的内容，但每一道菜的配方本身一定是不同的。Mac计算机的菜谱

    并不包括网络浏览器，而Linux菜谱的KDE部分刚好有一个名

    为“Konqueror”的章节。我们的策略是扯下这一章节，将剩下

    的内容全部抛弃，然后将扯下的这部分名为“Konqueror”的章

    节粘贴到Mac菜谱中。这会产生一个显而易见的问题：我们会破

    坏Konqueror这一章里面所有的位于被抛弃部分的交叉引用——

    在第123页不会有荷兰酱的制作方法了。

    要使这个插入页面的计划得以实现，在把Konqueror章节粘

    贴到Mac菜谱中之前，我们必须认真检查这一章节中的每一个索

    引。如果苹果软件中已经存在可以直接利用的索引内容，比如

    颜色、字体等通用计算机资源，我们可以直接重新建立索引。

    如果尚不存在可替代的索引内容，比如一个网址收藏系统，那

    么我们要从头开始写一份新的配方。我们认为，无论是在

    Konqueror还是Mac计算机上，这种改变都是能够让新的菜谱可

    以为大家所用的必要步骤。

    在编程方面，当我们将Konqueror的代码复制到Mac计算机

    中并尝试构建时，我们就知道不可能马上把它做好——任何一

    个失效的交叉引用都会导致编译错误。我们必须修正所有错

    误，而且我们知道这种错误不计其数，因此，我们不会立刻得

    到一个可用的浏览器。关键是，只要我们能够利用Konqueror源

    代码构建软件，我们就有了开发网络浏览器的坚实基础，在此

    之后，我们将不断地调试、排除故障、测试、优化代码。

    我们在策略中增加了最后一个重要元素。我们猜想，在

    Konqueror代码可以在Mac计算机上顺利运行之前，某些部分可

    能需要计划外的编程工作。我们决定给源代码添加注释，提醒

    我们稍后回到这里提高代码的适应性。程序员会经常使用这种

    注释，我们称之为“FIXMEs” ，对于这样一个即将开始的大

    型“移植”工程，我们会添加非常多的FIXMEs。几个月后，我

    们会感激自己此时所做的决定，之后，我们一直保留了这一工

    作习惯，只要在编辑代码时发现疑问，就会添加这个注释。每

    一个注释都是编程任务清单中的一项工作。

    总体来说，我们的策略有很多有利的地方。我们相信自己

    可以在不与任何自由软件许可产生冲突的前提下使用

    Konqueror。添加FIXMEs可以为成功构建软件后的调试和故障排

    除工作打下基础。首先开始的构建阶段的工作会非常直接——

    消除由失效的交叉引用带来的所有编译错误。12万行Konqueror

    代码分散在300个源代码文件当中，我们估计将全部文件编译完

    毕需要一两个月的时间，但不会超过两个月。

    这在当时听起来是没问题的，但是对于这项构建工作的乏

    味程度，我们完全没有做好心理准备。接下来你会看到，我是

    如何度过这段日子的。我尝试着构建一个Konqueror源代码文

    件，失败了，编译错误信息提示缺少交叉引用，这意味着在扯

    下Konqueror章节的过程中交叉引用被破坏了。接着，我解决了

    这个问题，重新构建，又出现了另外的错误信息。接着，修

    正、重启、报错，我一遍又一遍地重复这个过程。我坐在办公

    室里盯着计算机屏幕，构建、阅读，然后回应编译器的报错信

    息。我感觉自己就像存在主义戏剧里面的一个角色，注定要与

    编译器进行重复对话。第一幕 场景36

    库比蒂诺苹果无限循环总部，肯的办公室

    肯坐在他的座位上，双手置于键盘上方。他输入了一个可

    以调用编译器的命令，要求其编译一个名为kjs_bingding.cpp

    的文件。

    编译器：kjs_binding.cpp:error on line 200:use of

    undeclared identifier“rotocol”

    肯查询了与“protocol”相关的声明，将其输入编译器。

    肯：搞定了，编译器。我已经声明了“protocol”，请再

    试一次。

    肯再一次输入了调用编译器的命令，要求其编译名为

    kjs_bingding.cpp的文件。

    编 译 器 ： kjs_binding.cpp:erro on line 201:use of

    undeclared identifier“hst”

    肯查询了与“host”相关的声明，将其输入编译器。

    肯：天哪，我竟然遗漏了“host”的声明。搞定了，请再

    试一次。

    同样，肯输入了调用编译器的命令，要求其编译名为

    kjs_bingding.cpp的文件。

    编 译 器 ： kjs_binding.cpp:erro on line 202:use of

    undeclared identifier“prt”

    唐、理查德与我一起经历了构建测试版本的煎熬，在吃午

    餐和休息时，我们经常互相倾诉难以忍受的烦恼，并彼此同

    情。我们也无法把这项工作丢给初级程序员或实习生，苹果的

    工作方式不允许出现这样的行为。保密是其中的一个原因，但

    更重要的是，苹果不会把研发工作和软件实施工作分割开，我

    们必须负责网络浏览器项目从产生创意到交付给消费者的整个

    过程。

    面对枯燥乏味的工作，我们无从脱身，只能坚持。每一个

    小时的单调重复都是在推进“移植”工程，我们对每一份文件

    的浏览都是学习和理解被我们采用的源代码的机会。渐渐地，一天又一天，一星期又一星期，我们逐渐缩减了仍然需要用于

    构建的文件列表。

    我们对工作时间的预计是比较准确的，最终，我们按时完

    成了编译器错误信息的排查工作。Konqueror浏览器在Mac计算

    机上构建成功了，一个可以双击打开的应用程序出现在我们面

    前。当我们打开它时，全新的浏览器显示了一个空白的窗口，现在我们需要调用指令来让它从事浏览器的本职工作：加载网

    页。然而它无法进行这一步，我们尝试了很多次，而大多数时

    候程序会崩溃，其余时候浏览器似乎也无法完成任何任务。

    现在是我们添加的FIXMEs发挥作用的时候了。我们编写了

    在尝试加载网页时可以自动生成报告的代码。代码中每一个FIXME都在报告中体现为一个条目，它们很清晰地告诉我们，虽

    然我们的浏览器没有生成可视的网页界面，但在这一表象背

    后，在软件深处，浏览器依然做了很多工作。

    我们三个将目光投向紧挨着浏览器界面的FIXME报告界面，我们一边操作浏览器，一边关注当前的报告。我们的工作流程

    变成了这样：尝试加载页面，观察报告，变更源代码以解决

    FIXMEs呈现的最严重问题，然后重试。

    在调试阶段刚开始时，这个报告包含了众多条目：渲染图

    像未实施、网页链接未实施、运行Java脚本未实施……后来，随着改进代码的行动的持续进行，我们将很多“未实施”的条

    目更新为“部分实施”，当一个区域里面的FIXME全部被修订

    后，我们将区域中的注释全部移除。然而，当解决了不计其数

    的问题后，我们的浏览器窗口对任何指令都毫无反应。整个界

    面依然布满了白色的像素块，而大量的FIXME报告继续无情地指

    出我们接下来的工作还有很多。

    1. 直译为“修正我吧!”——译者注

    2. 译为：使用了未声明的“protocol”。——译者注

    3. 译为：使用了未声明的“host”。——译者注

    4. 译为：使用了未声明的“port”。——译者注

    黑色石碑

    我们继续坚持，在数星期单调枯燥的工作后，理查德不得

    不提出休息几天。他一直在专心研究对屏幕渲染元素非常重要

    的图形例程。他坚信自己很快就会消灭最后几个关键的

    FIXMEs。他与我做了简单交接，我接手了他的工作。经过几个

    小时的研究，我似乎找到了解决问题的关键，用拟人的方式来

    表达这个专业问题，就是我们想要画出网页，但手中的笔从来

    没有放在纸上。这有点儿类似于网络浏览器版本的空气吉他。

    我写了几行代码来处理这个问题，接着我构建了浏览器测试程

    序，然后打开了它。

    我键入了一个链接地址：http:www.yahoo.com。FIXME报

    告上出现了一行又一行提示，但浏览器没有崩溃。几秒钟后，浏览器开始工作，它给我画了一幅画(见图3-1)。图3-1 一块黑色石碑。我们的苹果浏览器真正意义上从互联网上加载的

    第一个“网页”

    我关上了浏览器程序，然后重试了一次。它加载出了跟以

    前一样的雅虎主页。FIXME报告的信息更新完毕，浏览器没有崩

    溃，它又出现了一个短暂的停顿……然后，同样的黑色长方形

    又出现了。

    我冲进走廊去找唐。当我们回来时，我关闭浏览器，然后

    重新加载雅虎主页。在同样的停顿期间，我们屏住呼吸……接

    着我们看到了同样的黑色长方形。我们的浏览器终于开始做点

    儿什么了!

    我们开始疯狂地叫喊，互拍后背，表现得好像电影

    《2001：太空漫游》里面的场景：我们灵长目动物的祖先被来

    自天外的黑条外星人造访，我们模仿了我们的祖先的样子，指

    指点点，大喊大叫。我再次尝试加载页面，又一次出现了黑色

    的石碑!这是真的!

    这个成就可能看似平凡，但我们非常激动。在理查德展示

    示例程序后的三个月里，尽管我们仅能通过数字间接记录我们

    取得的成绩——我们构建了多少源代码文件，修复了多少交叉

    引用，消除了多少个FIXME，但我们一直对移植策略抱有信心。

    而今天我们终于在浏览器窗口里真正看见了网页。

    唐和我一直在我们自己的黑色石碑中挣扎，艰难地穿越了

    长时间的黑暗，消除了对浏览器项目的怀疑，终于迎来了黎明

    的曙光。我在苹果工作期间只经历过两次“尤里卡时刻”，而这是

    其中之一。我为理查德没能与我们一起迎接这一时刻的到来而

    感到遗憾。他的示例程序向我们首次证明了Konqueror的潜力。

    遇见黑色石碑是第二次重大的飞跃，它证明了我们的移植策略

    是行之有效的，它是我们从示例程序向产品努力的过程中的里

    程碑。

    我们自此再也没有经历连续数星期毫无明确进展的日子。

    从能够看见网页加载开始，我们基本上每天都可以看到自己的

    浏览器变得越来越好。在那一星期结束以前，我们已经将黑色

    长方形变成了可以显示雅虎主页全部信息的页面。几天后，网

    页链接也被渲染成当时流行的蓝色加下划线的样式。接下来的

    那一星期，第一批图片被显示出来了。当加载出第一个网页

    时，我感觉自己好像按下了一个开关，灯终于亮了。

    灵感1%+汗水99%=发明创造

    如今，大多数人都将网络浏览器视为一种理所当然的存

    在，所以我把它比喻为电灯恰如其分。我们如今随时随地都在

    上网，根本不会去思考浏览器是一种需要被创造的技术。就如

    同当年的电灯一样，我想我们可以通过更详细地了解爱迪生于

    19世纪发明电灯泡的过程，来使读者了解我们在21世纪为浏览

    器开发所付出的努力。

    爱迪生一直在为解决技术上的难题而挣扎，包括他为了寻

    找能够发出明亮而持久的光的电灯泡灯丝而做出的种种努力。

    我喜欢这段来自一部于1910年出版的《伟大发明的故事》一书

    中的叙述：

    (爱迪生)坐在那里思考了整整一夜，他下意识地用手指

    拨弄混合了他用在电话上的焦油的灯黑(一种用煤烟制成的颜

    料)。他似乎没有多想，将灯黑和焦油的混合物揉成了一根

    线。当他意识到自己做了什么之后，灵感突然迸发：“为什么

    不试着让电流穿过这根线呢？”他立刻动手，结果只得到了一

    丝微弱的光芒。

    接下来，他决定寻找最合适的碳。他把各种纸张和木头进

    行碳化，但事实上，他能找到的所有东西都能够做成碳灯丝。

    他试了试日本竹扇的纤维，发现电流经过这种竹纤维时产生的

    光比之前经过所有材料时产生的光都要明亮。于是，他开始寻找最好的竹子。他了解到竹子的种类共有1200多种，所以他必

    须逐一尝试。他派人前往位于世界各地的竹子产区，其中有一

    个人，其行程超过3万英里，在寻找竹子的过程中在野外多次遭

    遇野兽。最终，一种产于日本的竹子在所有实验对象中脱颖而

    出。寻找碳纤维的整个过程大概花费了10万美元。

    这个小故事里面包含了所有元素：突然出现的灵感、勇敢

    无畏的人、遥远的征途、野兽、巨额资金。就连《伟大发明的

    故事》的作者都有一个听起来充满故事色彩的名字——埃尔默

    ·埃尔斯沃思·伯恩斯。

    当然，灯泡发明的真实情况远比故事复杂，我想我们完全

    可以合理怀疑爱迪生到底是不是真的在无意间把手指放在焦油

    和灯黑里，然后萌生了将电流穿过其中的想法。正如史蒂芬·

    约翰逊在《伟大创意的诞生》一书中写的那样：

    坊间盛传爱迪生是灯泡的发明者，但事实上，灯泡的诞生

    来源于爱迪生与其竞争对手你追我赶的过程……爱迪生站在了

    至少6个前人(包括约瑟夫·斯旺以及威廉·索耶)的成果的基

    础上。

    爱迪生并不是完全依靠自己的力量想出这个主意的，早在

    爱迪生开始研究碳纤维的适用性以前，碳就已经被用于灯泡灯

    丝的研究，约瑟夫·斯旺在碳身上做了大范围的实验。但这些

    先行者未能发明出实用的灯泡，而爱迪生做到了。其中的原因

    究竟是什么？我想，一个合理的解释必须包含以下因素：爱迪

    生将电灯照明视为复杂的发电与配电系统的设想，他作为发明

    家业已存在的历史业绩，他充分利用自己的声誉为研究工作融

    资的能力；而且，他富有远见地成立和领导了第一个以产品为

    导向的研发实验室，这个组织可以将很多人的努力有效地整合

    起来。

    所有因素都很重要，不过我认为爱迪生如此巨大的成功要

    归于他对细节的观察。我还是想把这个话题拉回爱迪生自己是

    如何描述建立创新工作基础路径的，尤其他是如何解决类似于

    为灯泡找到最优灯丝材料等问题的。我的任何一项发明都不是

    偶然产生的，我发现有需求需要被满足，于是我一次又一次地

    尝试，直到成功解决问题。这一切都可以归结为1%的灵感加上

    99%的汗水。

    按照这个说法，爱迪生本人是不是如同伯恩斯一样把事情

    过度简化了呢？如果爱迪生真的想编造一个令人信服的将自己

    的能力神化的故事，那么也许他应该编造出比“我非常努

    力”更生动的解释。作为传奇故事，这个解释太苍白了，毫无

    神秘色彩，就好像爱迪生在告诉我们：“就算我真的像伯恩斯

    所说的那样混合了焦油和灯黑，这种偶然出现的灵感在大局中

    也没有太大价值。”对于爱迪生来说，更重要的事情是构建有

    远见的设想，然后持续不断地努力，直到一个真正的产品被发

    明出来。

    作为一名工程师，我对爱迪生提出的数字很感兴趣。灵感

    与汗水的1∶99的比例关系听起来很夸张，是吧？但是我们为苹

    果网络浏览器的开发过程提供了可供验证的数据。理查德的示

    例程序就是我们的灵感。唐、理查德和我从这里出发，不断地努力，直到黑色石碑出现。我们把工作时间进行分解，如图3-2

    所示：

    图3-2 浏览器项目的爱迪生比例

    乍一看，这个1∶75的比例好像在说，爱迪生对所需努力的

    程度高估了25%，但这是一个重大错误。然而，在做这个表述

    时，爱迪生指的是一个已经完成的发明。正如我所说的，黑色

    石碑的出现是我们浏览器项目的重要里程碑，但距离最终完成

    还需要一年的时间。你还记得黑色石碑意味着什么吗？它意味

    着我们全新的浏览器代码第一次执行操作，而不是不回应、崩

    溃或者在FIXME报告上汇报错误。尽管我们仍处在项目开发阶段

    的早期，我们预计在推出最终产品之前仍需要很久的工作，但

    此时，灵感与汗水的比例已经是1∶75了。从这个角度来看，爱

    迪生严重低估了汗水的权重。

    我怀疑爱迪生认为他提出了一个物理定律或者期望1∶99的

    比例是一个通用常数。即便如此，他的经验也让他在发明创造

    的过程中体会到了一件事：努力是至关重要的。

    我们总希望相信像爱迪生这样的天才可凭空变出改变世界

    的发明。简单的解释是很诱人的，爱迪生产生的这种灵感看起

    来富有魔幻色彩；而我们都知道，为之付出汗水是一件苦差

    事。当伯恩斯写下这些关于白炽灯等著名发明的故事时，他更

    加突出一个存在于想象中的魔法时刻。爱迪生则很清楚，真实

    的故事其实是痛苦和枯燥的。

    我同意爱迪生的说法。如果不付出努力，想法再好也无法

    成为现实。尽管我们开发的网络浏览器对整个人类社会没有那

    么深远的意义，但我相信，这一点适用于爱迪生寻找灯丝材料

    的过程，也同样适用于我们开发浏览器的过程。

    想象一下，如果我们没有在理查德做出示例程序后立刻着

    手开发并实施我们的移植策略，那么现在的情况并不会比当初

    苦熬6个星期毫无成果更好，我们可能依然没有可以向上级汇报

    的成果。如果我们三个没有咬紧牙关、埋头苦干、拼尽全力、逐步构建代码、修正交叉引用、研究FIXME，并最终等到黑色石

    碑出现，那么理查德的示例程序依旧不过是一个程序玩具。但是真的是这样吗？开发一个网络浏览器，仅仅有一个好

    的示例程序和一些耗费体力的编程工作就可以了吗？既然爱迪

    生认为天马行空的想象和头脑风暴只需要很少的时间，那么占

    据其他时间的99%的努力到底是什么？

    爱迪生用非常简短的一句话告诉我们：“我一次又一次地

    尝试，直到成功那一刻的到来。”他和他的团队愿意挥洒汗

    水，但他很清楚在所有的这些时间里面他们需要经历什么：反

    复试验。对于灯泡这个产品来说，灯丝是其中的关键，而竹子

    是最有潜力的灯丝材料，所以爱迪生对所有品种的竹子进行测

    试，以找到最适合的那一种。如果伯恩斯的话可信，那么这意

    味着爱迪生试验了世界上的全部1200种竹子。这个工作听起来

    很简单，事实也确实如此，但是爱迪生将有价值的工作从任务

    清单中标记了出来。

    当我们为网络浏览器项目确定移植策略时，我们采用了爱

    迪生的行为模式。我们知道编译器会告诉我们被破坏的交叉引

    用，然后我们逐一检查并修改。我们知道FIXME会告诉我们哪里

    的代码存在问题，于是我们认真研究这个报告。向黑色石碑出

    现的那一刻努力是一个循序渐进的过程，就像爱迪生寻找最合

    适的竹子一样。爱迪生为了寻找灯丝反复尝试；而我们在构建

    软件的过程中一个文件一个文件地编译，为了加载网页我们排

    查每一个FIXME。这两个项目都建立在大量重复枯燥的劳动之

    上，但是细节至关重要。爱迪生并不是在沙漠里漫无目的地跋

    涉，希望翻过下一个沙丘就能找到一片绿洲——这听起来好像

    是唐和我在最初的6个星期做的事情。相反，爱迪生是在确定了

    以竹子为材料后，为了找到最适合的竹子而百折不挠，试验了

    所有种类的竹子。每一个被划掉的名字都使他与最终结果的距

    离更近。在为黑色石碑的出现而努力的过程中，我们也经历了

    同样的事情。尽管唐、理查德和我都在枯燥乏味的工作中苦苦

    挣扎，但我们仍然坚持不放过每一个文件、每一个FIXME。

    坚持努力是一件很困难的事情。没有勤奋，灵感也无法结

    出硕果。我们分工合作，共同完成了浩如烟海的案头工作。我

    们对技术(代码、编译器、软件许可以及调试)的理解和掌握

    使我们有信心向前迈进，并投入了大量的时间和精力，最终使

    理查德的示例程序成为真正的产品。

    当然，一个仅能显示黑色石碑的程序还远不是一个功能完

    整的网络浏览器。在开发出最终的应用程序前，我们还有很长

    的路要走，但在技术层面，黎明已至，曙光初现，至少我们能

    够看清未来的路在何方。第4章 乔布斯要的是速度更快

    直至今日，我仍清晰地记得那一刻我手中湿冷的感觉，史

    蒂夫向大家郑重宣布：苹果已经开发了自己的网络浏览器。一

    瞬间，我们的超级秘密——这个开发周期长达18个月的项目

    ——成了众所周知的事情。史蒂夫向大家宣布，Safari加载网

    页的速度比IE浏览器快了不只一点儿，而是整整三倍。

    这个项目起步时，我们的团队只有三个程序员。我们在几

    个月之内又找到了几个人，组成了一个9人的小型团队，现在正

    准备在网络浏览器项目上放手一搏。

    替代IE浏览器

    当时，有消息从管理层传出来，史蒂夫·乔布斯已经决定

    了他评判我们浏览器项目的标准，其关键点只有一个：速度。

    史蒂夫希望我们的浏览器速度快，从互联网上加载网页的速度

    要足够快，必须远远超过Mac计算机上默认使用的微软IE浏览器

    才可以，因为我们的浏览器存在的目的就是完全替换IE浏览

    器。

    在苹果，我们总是试着提供开箱即用的最好的产品，除了

    速度这个方面，我们还需要为浏览器提供一整套功能，其中，出色的书签管理、精简的用户界面这两项在开发清单上占据了

    最重要的位置。不过我们的团队在当下还是把重心放在提高速

    度这一目标上。上述挑战给了我们明确的目标。在我们多人在

    线聊天频道的记录里，充斥着各种各样的技术问题、对最新难

    题的陈述及解决问题的思路、修改代码的请求等等。在我们的

    团队中，差不多有四五个人每天都在一起吃午餐，我们一小群

    人步行至位于库比蒂诺总部无限循环2号楼和4号楼之间的员工

    自助餐厅，我们彼此之间距离很近，所有人都可以同时参与任

    何关于技术的讨论。我习惯于等所有人都点好餐回到餐桌上之

    后再开始用餐，我会调侃他们，让他们羞愧到一言不发、眼神

    游离、低头扬眉。等所有人都到齐后，我们一起开始用餐，我

    们不是一家人，但我们是携手并肩的团队。我们是苹果式合作的一个典型，一个小团队为共同的目标齐心协力，而我们的目

    标就是开发一个速度足够快的网络浏览器。

    此外，我们很清楚自己正在试图去做的产品替代是一件很

    棘手的事情。一旦苹果将新浏览器作为Mac计算机的默认浏览

    器，我们绝不希望用户来质疑公司的决定。史蒂夫认为，一个

    能提供高速上网功能的苹果浏览器，是让用户忘记IE浏览器并

    立刻喜欢上我们这个替代品的最佳方式。

    速度也是史蒂夫对未来互联网发展趋势的洞察的一部分。

    如果你曾经历过那个时期——21世纪初期，那么你一定记得当

    时让人痛苦的网速，当时几乎没有人能够享受到如今我们所说

    的宽带。网页在加载时会不停地闪动，图片会在经历几个模糊

    不清的阶段后才逐渐变得清晰。每个人都清楚高速上网的时代

    即将来临，随着网络速度的提升，数据量也将日益增长，史蒂

    夫希望我们的浏览器能够做好准备迎接即将到来的浪潮。我们

    的代码编写工作需要继续深入。史蒂夫认为加载速度对浏览器

    体验有长期的影响，所以开发一个高性能的浏览器成为我们的

    首要目标，我们要定义卓越。

    我们还有很长的路要走。2002年春末，我们的浏览器只能

    缓慢地加载页面，我们无法进行日常浏览或做其他类似的事

    情。有时，新闻网站上的字体会模糊不清，难以辨识；电子商

    务网站上的购物车会丢失东西；银行网站的登录栏会因无法使

    用而导致我们不能查询账户信息。浏览器的速度非常慢：从互

    联网上加载数据很慢，显示图像很慢，返回上一页也很慢。

    修正无法正确显示网址的错误已经占据了我们大量的时

    间，但由于史蒂夫对浏览器响应速度的要求，我们不得不同时

    研究如何使浏览器更快速地工作。PLT——软件调试官

    唐是那个想出解决办法的人。大约在黑色石碑出现后的一

    两个月中的一天，唐把我叫进了他的办公室，让我制作一个可

    以测定浏览器速度的测试程序。在他的构想里，这个程序应该

    可以自动开启浏览器，让它以极快的速度一个接一个地加载一

    系列网页。接下来几天，我按照他的设想完成了这个程序。我

    把它命名为网页加载测试(Page Load Test)，不久后，我们

    就把它简称为PLT。

    PLT成了我们的软件调试教练，它像一个手握虚拟秒表、训

    练有素的教官。当我们在PLT的界面上按下“开始”键时，测试

    程序从列表中的第一个URL链接开始查看，仿佛在浏览器中大声

    呼叫这个网址的名字，按下秒表，然后等待浏览器加载页面。

    当页面完全加载并渲染好之后，PLT再次按下秒表，记录时间，然后呼叫列表上的下一个名字。

    唐为PLT的测试列表筛选了40个尽可能复杂的网页。他挑选

    了文字很多的网页，比如雅虎(Yahoo!)，以及图片很多的网

    页，比如迪士尼(Disney)。他给出的列表涵盖了用户最常访

    问的网址，比如你熟知的亚马逊(Amazon)、谷歌(Google)

    和易贝网(eBay)等，还有一些如今已被遗忘的网址，比如

    Real Networks、Webcrawler以及iVillage等。汇集在一起的网

    址涵盖了影响网页加载和渲染速度的所有因素，以确保尽可能

    多地暴露浏览器的弱点。

    PLT在自动加载了列表上的全部URL链接后，会自动计算加

    载一个网页的平均时间。当时，这是检测浏览器速度的细分测

    量方法，这个数字成为唐整个计划的关键点。他发布了一份管

    理公告：在PLT没有运行期间，不允许更改任何代码。

    这个关于PLT的公告是什么意思？为什么如此重要？在我们

    的浏览器项目团队中，与其他任何重要的软件开发工作一样，我们在做源代码更改的时候要遵循一套编辑流程。在编辑完一

    段代码后，我必须写下详细的概要，解释清楚本次编辑做了哪

    些修改，实现了什么功能，修正了什么错误，以及我认为这次

    代码更改在多大程度上实现了这些目标。接着，我会让另一位

    团队成员与我一起评审这项工作。代码评审的过程通常是一轮

    接一轮的反馈、改进、再次评审。只有某项工作通过了同级评

    审，我才被允许将所做的修改上传至存储所有源代码修改信息

    的中央处理器——版本库。

    在PLT投入使用以前，我们的编辑流程主要考虑功能实现、故障修复以及网络标准协同等因素，这些因素与浏览器能否更

    好地实现其预设功能，是定性的方法。PLT检测响应速度，是一

    种定量测试，为我们每一次代码的更改都提供了独立的评价手

    段。现在，正确性和速度并驾齐驱。唐认为，如果我们关注PLT

    给出的结果，不接受使浏览器运行速度变慢的代码修改，那么

    只会出现两种结果。浏览器要么保持原来的速度，要么变得更

    快。他一边用食指敲打太阳穴，一边强调这套取巧的逻辑。在

    PLT被开发出来的那一天，唐就向大家宣布，我们的浏览器速度

    不会变得更慢，只会变得越来越快，这就是他的禅心印。用PLT运行新代码成了我们每日的例行工作，有时甚至是每

    小时的例行工作。我经常使用它来测试，两组功能相近但略有

    区别的代码中哪一组更快。当需要对代码做出更改时，如果新

    代码让浏览器运行得更快，那么它可以被通过，否则就会被放

    弃。大多数对代码的编辑对浏览器的表现没有影响，有一些却

    产生了很大的影响，只要这种改变能够使速度变快，代码更改

    就可以被接受。我们也会遇到幸运的意外——移除冗余的FIXME

    有时会带来意料之外的提速。高质量的代码通常会带来更快的

    响应速度。

    当我们使新闻网站上的文字变得清晰，使电子商务网站上

    的购物车不再丢失物品，使浏览器具有兼容性并且能让用户登

    录银行网站管理个人账户时，我们都必须在保证速度的前提下

    改进浏览器的各项功能。

    没有任何事情可以打破“速度底线”这个规则——唐绝不

    会让步(见图4-1)。当一个重要功能的新代码导致速度降低

    时，事情变得棘手起来。要保证速度必须放弃软件的部分优

    化，“优化”这个术语值得我解释一番。

    图4-1 唐·梅尔顿与我们的团队优化与速度底线

    即便在程序员群体里，能称得上著名计算机科学家的人也

    很少，不过高德纳绝对担得起这个头衔。他是计算机科学领域

    奠基教材之一《计算机程序设计艺术》的作者，这是一套多卷

    的学术论文，他从1962年开始，像僧侣一样怀着苦行主义精神

    和虔诚的心态从事创作。高德纳进行了一丝不苟的研究，认真

    地撰 ......