Yurii译文集


按:今天在网上看到阮一峰推荐的《Hype Driven Development》,忍俊不禁,联想到工作中的很多经历又百感交集。趁春节假期翻译出来(练练手),与大家共享。


软件开发团队所做的软件架构或技术栈的决策,很多并没有经过踏实的研究和对目标成果的认真思考,而是不准确的意见、社交媒体的信息,或者就些是“热闹”的玩意。我称这种作派为“热闹驱动开发(Hype Driven Development,HDD)”,眼见它的危害,我赞成更专业的做法,就是“脚踏实地的软件工程”。下面我们一起看看HDD的来龙去脉,想想能如何改进。

(more…)

本文翻译自 TokuMX Fractal Tree(R) indexes, what are they?

TokuMX的一大创新在于,它打破了一条长久存在的关于数据库的规则:要保证好的写入性能,索引的工作集应当能够放在内存里。标准答案是这样的:如果索引的工作集比内存要大,写入就需要执行I/O,I/O就会成为限制因素,性能就会下降。所以,要么让索引小到能全部放进内存,要么提供一种索引写入模式,避免工作集过大,比如MongoDB所采用的,内存中只为最近插入的数据保存索引。

但对TokuMX来说,这是绝对不成立的。依靠TokuMX所提供的创新性的分形树索引,索引的工作集可以比内存更大,同时写入性能不受影响。分形树索引为什么在重度写入(无论是MongoDB还是MySQL)的评测中能表现优异,原因就在这里。

(more…)

按:此为最近我翻译的《简约之美(Code Simplicity)》的译者序。

1776年,美国独立战争爆发,当时北美尚有很多民众对“独立”充满怀疑: “北美真的要脱离英国吗”、“新的国家需要怎样组织”,这些今天看来不是问题的问题,并没有清晰明确的答案。就在此时,有位叫托马斯•潘恩(Thomas Paine)的人站了出来,单枪匹马解开了人们心中的疑惑,大大鼓舞了北美民众的独立情绪,而他所依靠的,只是一本名为《常识》的小册子。

《常识》这本小册子说了什么呢?我随便摘录几句:

如果没有人监督,对国王是不能信任的;或者换句话说,渴望保持专制政权的欲念是君主政体的固有弊病

独立自主的问题不外乎意味着:究竟是我们将自己制定我们的法律,还是让这个大陆的目前和将来最大的敌人——英王来吩咐我们,除我所喜欢的法律以外不准有任何法律

让我们为宪章加冕,从而使世人知道我们是否赞成君主政体,知道北美的法律就是国王

200多年后再读,仍然可以感受到这些文字的力量,所以不难想象,在美国独立战争时告知民众这些道理,能发挥多么重要的作用——据载,在当时只有二百多万人的 北美,成年男子几乎人手一册《常识》。不夸张地说,这本书推动了美国建国的进程。

潘恩既不是高明的政治哲学家,也不是熟谙宣传的政客,他的书也谈不上多么高深,在我看来,主要原因是《常识》用朴素平实的语言把道理讲出来,告诉大家“原来是这样的”。换句话说,许多道理其实并不高深,但必须以“常识”的形式表达出来,大家才能听进去;否则,终究难逃曲高和寡的悲惨命运。

读者或许会觉得奇怪,一本技术书籍的译者序,为什么要花这么多篇幅介绍历史呢?之所以这么做,是因为我在翻译这本看似平淡无奇的书籍时,数次想到托马斯•潘恩的《常识》。我深刻觉得,在软件开发的各种书籍和资料中,也应当有类似《常识》的文本来告诉大家:道理原来是这样的,就是这样。

我相信,任何一位读者,只要认真看过全书,都会发现《简约之美》其实只强调了几条非常简单的道理:

  1. 软件是必然要变化的,变化乃是常态;
  2. 有变化就需要维护,随时间推移,维护成本会远远超过初期开发的成本,占据成本的大头;
  3. 因此,在软件开发中,最重要的是要降低维护成本;
  4. 维护成本正比于系统的复杂程度,所以要降低维护成本,系统的设计就应当追求简单清晰;

这链条看似简单,其实并非如此。不少有经验的开发人员,似乎对这类“道理”不屑一顾,他们更在意新潮的技术、先进的架构、流行的语言……新出了哪种类库,什么软件新发布了版本,大数据该怎么处理,说起来头头是道,但真刀真枪地写起程序来,往往错漏百出(甚至不自知)。

我曾经见过一套系统,设计和开发这套系统的人几乎用到了.Net的所有高级特性,但95%以上都用错了,结果就是系统层次混乱、类责任混淆、通讯完全不可靠。诡异的是,许多错误都属于“地雷”,如果业务一直维持在原始状态,它们几乎不会爆炸。不幸,业务无可避免地要扩展、要增长、要规范,于是地雷一颗接一颗地爆炸,只能投入大量优秀程序员,花比开发时多好几倍的精力,去维护和重构系统,才勉强保证了业务的发展。最终,当系统重构告一段落之后回头看,其实所谓的“维护”,也无非是“降低维护成本”,一点点地去掉之前那些花哨的特性,用简单的技术构建清晰的架构,而已。

就我所见,上面这种情况并不罕见,反而非常常见,更糟糕的是,还有许多项目始终不得解脱,被高昂的维护成本死死困住;即便推倒重来,因为设计和开发仍然缺乏对“降低维护成本”的足够重视,导致悲剧重现……

说起来,这一切的根源都是因为目标不明确,没有考虑且不重视维护成本,也没有考虑设计的简洁清晰。其中的道理不算复杂,但怎么才能让大家明白?这个问题我一直在思考,所以在翻译本书时,才会反复想起托马斯•潘恩的《常识》——软件开发需要常识,软件开发的资料里需要《常识》之类的读本,不需要艰深的道理,也不需要花哨的说辞。潘恩的《常识》用短小的篇幅向广大民众澄清了“北美应该独立,且不需要国王”,我希望《简约之美》也能用短小的篇幅向广大开发人员说明“应当重视软件的维护成本,追求简单清晰的设计”。

Code Simplicity

我为何爱读代码?你为何也应当爱?

原文:Why I Love Reading Other People’s Code And You Should Too by Alan Skorkin

翻译:Yurii

我恨读代码

我发现,许多程序员都讨厌读代码——拜托别掩饰了,承认吧。差不多每个人都喜欢写代码——写代码乐在其中。可是,读代码真是不容易,而且还很烦人,又无可逃避,其他人写的代码总是很垃圾(即便不说,我们心里也这么想的)。即使自己写的代码,过几个小时再看也有点垃圾,过的时间再久点,就更垃圾了。那么,还有什么理由去看别人的蹩脚代码,而是不自己写几手漂亮的?能不能暂且忽略这个问题,花上几个小时看别人的代码,再回头来看自己的是不是还那么漂亮?即便有位大师坐在你面前,如果你不能从他身上学习,你永远也成不了大师。办法之一就是找到这么一位大师,让他手把手地教会你全部知识。有这可能吗?——当然有,只是很难遇到这顶好的运气。不过你也不必奢求那么幸运,做程序员这行就很幸运,因为大师们的所有思想和技艺都凝铸在他们的代码里,供我们学习。你要做的只是阅读代码——当然,如果有人给你一点点地讲肯定更节省时间,但这基本属于痴人说梦。换句话说,要相当个好木匠,得仔细研究大量的精美家具。

我热爱读代码,我总是直观地认为读代码的收获很大,没错,它可能有点讨厌甚至烦人,但你的收益绝对大过这点麻烦。举个例子,你要当大作家,是不是只关心自己写东西就够了?你可以试试看,但是估计不会折腾不出什么名堂。公认的事实是,多数大作家都是会如饥似渴大量阅读的。想写出好的作品,必须先阅读其他大作家的作品,吸收不同的风格,了解他人的尝试,然后才可以培养自己的创造力。这样,你的知识才能逐渐积累,最终你写的东西才有几分成熟,你也才会找到“感觉”。写代码也是这样,如果你不去阅读那些伟大的代码,怎么可能把程序写的漂亮?阅读伟大的代码之于程序员,就如同阅读伟大作品之于作家(我不敢掠美,这句话是Peter Norvig(译注:Peter Norvig是著名的Lisp程序员,现任Google研发总监)说的,他可不是个简单人物,所以好好记住这句话吧)。

即使上面说的你都不信,但有个事实无可否认。要想当个称职的开发人员,能熟练阅读代码是非常重要的。如今,只要不是闹着玩的项目,都是团队协作的成果,所以总会有这样的代码:它不是你写的,但你必须跟它打交道,去修改,或者去扩展。于是,阅读代码很可能就是你身上最重要最常用的能力了,咬紧牙关练好这门本事吧——而且,要快。

要像…会读代码的那些家伙一样…阅读代码

我都说不清有多少次见过这样的事情了:程序员把一段不熟悉的代码上下拖动,几分钟之后仍然一脸迷离。不久他们就宣布,这段代码根本没法看懂,更不必浪费时间了,可以想办法绕过这个问题。我不知道他们真正要做的是什么,一点点弄明白这段代码的意思,还是睁大眼睛等着开窍?阅读代码不靠成年累月死盯着看,你要做的是弄懂它,把它变成自己的。下面说的是我用的一些技巧,但不是全部,不过我觉得这些非常有用。

看代码看到目光迷离

1. 尝试亲自构建和运行程序。通常这一步很容易做到,比如你看的是真正运行的工作代码时(而不是不知来源的古怪代码)就是如此。不过也不是每次都很容易,如果不能很容易地构建和运行,你可以在完成构建和运行的过程中,认识到代码的高层结构。而且,阅读工作代码,你会非常熟悉如何构建项目。构建通常是复杂的,但是了解构建过程,知道代码是如何变为可执行程序的,会大大加深你的理解。

2. 别死盯细节。读代码要做的第一件事,是找到对代码的结构和风格的感觉。开始应当浏览,并且努力找出各部分代码都在干什么。这样你能熟悉整套代码的高层结构,也会明白你正在看的是什么样的代码(重构良好的,还是乱成一团的)。这时候你要做的就是找到入口(可能是main函数,也可能是servlet,controller之类),看看下面的分支是怎么展开的。这一步不要花太多时间,你对全部代码更熟悉之后,随时可以退回来。

3. 确保理解所有构造(construct)。除非你非常精通这门编程语言,否则多半还有些东西是你不知道的。在概略了解代码的阶段,要记下每一个不熟悉的构造。如果这样的构造有很多,下一步就不言自明了。如果搞不懂代码行为的意义,你什么也干不了。即便你不熟悉的只是少数构造,仔细观察推敲没准也是好事。你可能会找到一些以前不知道的关于这门编程语言的知识,我就很乐意为此花上几个小时。

4. 待熟悉了大多数构造之后,就可以搞几次随机的深入探查了。做法类似第2步,快速浏览代码库,但是这次要随机抽几个函数或者类,一行行地看下去。真正的考验现在才开始,但你的收益也是从这一步开始显现。主旨是:真正深入到你所阅读的整套代码的概念体系(组件结构)当中。这又是一个速度快不起来的步骤,但是在这一步,一定要尝试深入理解若干繁杂的细节。和第2步一样,在这一步,每次你多了解了一些上下文再回头看看,你的理解就更深入一些。

5. 前几步中肯定还有你不明白的地方,现在最合适的就是跑几个测试,看看已有的测试。测试很可能会大大打消你的疑惑,加深你对所测试代码的理解。我时常不能理解,为什么有些开发人员在阅读和理解代码时,忽略严密而精巧的测试套件。当然,也有时候是因为没有测试程序。

6. 如果没有测试程序,这时候就该写上几个。这样做有很多好处,它会加深自己的理解,它可以完善整个代码库,在阅读代码的时候也在写代码,这样对已有代码和你都有好处,你也可以真正动手参与进去。即便有现成的测试程序,为了加深自己的理解,你也可以再写一些。测试人家的代码,一般要求换个角度思考,之前你感到迷惑的概念也会变得更清楚。

7. 把弄不懂的部分拿到单独的程序中来。我发现,读代码时这样做,哪怕只是为了调节阅读的节奏,也是非常有乐趣的。即使你不理解代码的底层细节,也可能会对代码的功能有些高层面的想法。那为什么不把一些功能抽到单独的程序中测试呢?如果只运行一小段程序,debug就容易多了,而且这样的过程反过来又会加深你的理解。

8. 代码很乱(dirty)很糟糕(smelly)?那么重构吧。我可不是建议你把整个代码库推倒重来,但是重构一些部分确实可以让你的理解更上层楼。一开始要做的是把你明白了的功能变为独立的函数。在你真正理解之前,重构之前的函数只是看起来没问题,而重构可以把它们变成你想要的样子。依靠重构,你可以把代码变成自己的,而不要全部重写。好的测试程序可以帮上忙,不过如果你没有,就一边测试一边重构吧,而且只改动那些你确认弄懂了的功能。即便测试看起来太少太不完善,也要相信你自己的开发水平,有时候你只管大胆尝试就好(如果确实需要,总是可以回退(revert)的)。

9. 如果上面说的都不管用,就找个同伴跟你一起读代码。能从读代码中受益的可能并不只有你一个人,所以不妨抓住其他人,一起阅读。不过别找专家,他们给你的解释都是高层面的,这样看代码时注意的那些细节就都被忽略了。如果找不到人一起阅读,你又实在看不懂,有时最好的办法就是问别人。可以问你的同事,如果你在读的代码是开源的,也可以在网上问问其他人。记住,这只是最后的办法,不要一开始就这么做。

如果时间很紧张,短时间内必须弄懂某些代码,上面的步骤中只能选一步,我会选择重构(第8步)。你可能没法明白太多东西,但你肯定可以理解真正动过的部分。无论时间是不是紧张,你要记住的是:如果你第一次接触重要的代码库,肯定不能一下子就看懂,甚至不可能很快看懂。你可能需要耐心读上几天,几周甚至几个月——坦然面对就好。即便有专家坐在你身边,也省不了太多时间(我写的关于教和学的系列文章最后一篇就会谈这个问题)。如果你读(或者写)代码的耐心足够,方法得当,你肯定能成为对项目所有方面都非常熟悉的人,也是大家对代码库有问题时出面解答问题的人。你也可以不阅读代码,选择成为那个总想找人来解释的家伙。我想要做哪样的人,我自己很清楚。

抓住阅读代码的机会,别错过

我们都喜欢新写代码,它的诱惑力在于,我们能搞定问题。起码,这次搞不定,下次可以搞定。真相是:你在实践中不断提高,永远不可能一下就彻底搞定。这就是新写代码的价值所在,你在练习,你的水平在提高,但是阅读和改动其他人写的代码也很有价值(至少不亚于自己重新写),从中你学习到的不光是有价值的技术知识,还有关于整个工作领域的知识(毕竟,代码才是文档的最终形式),这种知识通常更有价值。

每一段不遵循传统的,莫测难懂的代码,都是有价值的。你知道我说的是什么,虽然它看起来一团糟,但本意并非如此(也可能因为它是Perl代码:))。每次我看到这样的代码,我都这么想。不妨把阅读它当作猜谜游戏,想想你能学到什么。是的,这很折磨人,但必须承认,你也希望能动手就能写出这么糟糕的代码。如果你花时间阅读这样的代码,你肯定更可能写出这样的代码——这倒不是说,你一定会写这样的代码,但你肯定希望自己能够。最后要说的是,态度总是非常重要的。如果你把阅读代码看作闲杂事,那它就是闲杂事,而你肯定会逃避,但是如果你把它看成机会,事情就不一样了。

愚人节放送:以美国为首的西方国家,悍然干涉南非实行种族隔离政策的内政,并最终得逞,南非的教训值得我们重视!

Yurii翻译自http://en.wikipedia.org/wiki/Disinvestment_from_South_Africa,本文遵守GFDLCC-BY-SA 3.0协议。

南非撤资运动

Disinvestment from South Africa

南非撤资运动,初始于20世纪60年代,撤资运动目的在于抵制南非的种族隔离制度,但直到20世纪80年代才大规模开展。1986年,美国以联邦立法的形式推行了撤资行动(disinvestment campaign),据信,该行动迫使南非政府开始就种族隔离问题进行谈判,并最终废除了种族隔离制度。

在联合国的运动(1962-1965)

1962年11月,联合国大会通过了1761号非强制决议,成立了联合国反对种族隔离制度特别委员会( United Nations Special Committee against Apartheid),呼吁对南非实行经济等方面的制裁。所有西方国家都对制裁呼吁表示不满,抵制该委员会。
此决议的议案出台之后,总部位于英国的反种族隔离运动组织(Anti-Apartheid Movement,AAM)牵头安排了1964年4月在伦敦召开的关于制裁的国际会议。按照Lisson的说法:大会的目的是得出经济制裁方案的可行性,以及制裁对南非、英国、美国及其保护国的经济所产生的影响。因为知道对制裁行动最强烈的反对来自西方(包括身处西方的英国),该委员会竭尽全力多方向吸引社会各界人士发出声音、参与大会,保证大会结论的公正。
本次大会名为对南非进行经济制裁的国际大会(International Conference for Economic Sanctions Against South Africa)。Lisson是这样评价的:

确立了国际社会有组织的对南非进行经济制裁的必要性、合法性和可行性,该国的政策被视为对南非和世界之和平与安全的直接威胁。会议结果同时指出,为保证制裁产生效力,制裁方案必须有美国和英国参与,虽然两国也是执行制裁方案的主要障碍。

尝试说服英国政策制定者

大会并没有成功说服英国对南非进行经济制裁。相反,英国政府“坚持自己的观点,认为制裁是不符合宪法的,因为‘我们认为南非政府的做法并没有对国际和平与安全产生威胁,也不相信制裁能够对说服南非政府改变政策产生实质影响’”。
反种族隔离运动组织(AAM)尝试把制裁成为1964年英国大选的辩题之一,质询候选人对南非实行经济制裁并采取其它惩罚性措施的看法。大多数候选人都给出了肯定的回答。但是,获胜后的工党完全放弃了之前对种族隔离问题的承诺。随即,工党领袖Harold Wilson告诉媒体:工党“不会选择经济制裁,即便制裁真的有效,也会影响到我们最关心的人——必须要保持某种优雅生活的南非白人和黑人”。即便根据Lisson的说法,即便如此“AAM仍然希望新的工党政府能够比前任政府更好地感知公众的要求”。但是到1964年,形势已经很明显了,选举工党上台丝毫也没有改变政府对经济制裁的抵制态度。

西方的坚决反对

Lisson也概要描述了1964年在联合国令人失望的局势:

在联合国,英国始终不认可这一说法:南非的做法违背了联合国宪章第七条。相反,英国在美国的配合下,英国出台了对瑞佛尼亚审判(译注:1964年的瑞佛尼亚审判中,曼德拉和非洲民族议会的其他领导人被判处终身监禁)和其它政治判罪的言辞审慎的声明,尝试安抚亚非国家和本国及外国公众的意见,到1965年,制裁提议就无人问津了。

根据Lission的说法,英国的反对态度是以其在南非的经济利益为前提的,采取任何有实质意义的经济制裁,都会对这些利益产生威胁。

(more…)

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Livingston:你提到,Gmail最开始是“有争议的”,能接着说下去吗?

Buchheit:我觉得,一般来说,人们会不太适应不一样的东西。即使是现在,我谈到给Gmail增加新特性,除非是很小的改动,或是不改变现状,只做些调整,否则大家都不会喜欢。人们对“可能”的理解非常狭隘,相比真正的可能性,对于“可能”,我们的思维有许多局限。所以他们会不适应,他们有点喜欢想尽办法来反对。
但是我个人更钟爱新的东西,所以我总是非常愿意看看会发生的事情。这是我加入Google的最大理由。这理由足够强,强到我确信这是一桩好事:我只是觉得这很有意思,看到将要发生的事情,我很激动。
就这样,Gmail之所以让我激动,也是因为想看看大家会是什么反应。我喜欢某些不确定,因为这有点悬念、有点激动,好像是冒险,对吧?即便没有做成,你也可以从中学到很多。但不是每个人都喜欢冒险。许多人好像就是讨厌不确定。在生活的每个方面都讨厌不确定。
我忽然想起来,某段时间我问大家,如果他们在玩俄罗斯轮盘赌,有一把枪,枪有10亿个弹筒(或者非常多的,也就是说,他们被杀的可能性微乎其微),他们愿意花多少钱玩一盘?许多人都觉得这个问题很不礼貌,他们回答,“给我多少钱我也不玩”。但我们其实每天都在玩这个游戏。他们开车来上班,挣工资,其实一路都是在冒险,但是他们不希望知道自己其实在冒险。他们希望自欺欺人,假装一切都与风险无关。

(more…)

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Livingston: 那时候Google一门心思关注搜索,你有没有担心过自己的项目被抛弃?

Buchheit:一直都是。我还得说,现在看来Gmail很不错,但我们开发是很早时候的事了。Gmail是第一个真正偏离单纯“web搜索”的产品。Groups其实也依赖搜索——只不过它搜索新闻组里公开的帖子。

Livingston:Gmail还必须要邀请才能加入吗?

Buchheit:不用,你可以用手机申请。

Livingston:也可以通过Blogger,对吗?

Buchheit:我们已经向许多不同的方面开放了。大学生可以申请,我们希望开放给学生。

Livingston:为什么要邀请加入,这背后是怎么想的?

Buchheit:理由有好几个。我又得说一遍,邮件的问题很麻烦,不只是在数据规模那些方面。有个问题很重要,那就是,我不希望数据有任何损失,因为没人愿意弄丢邮件。如果web搜索出了问题,你可以退回去,重抓一遍网页,但是邮件不同,一旦丢了就不可挽回。
我非常关心系统的稳定性。策略之一就是控制用户的规模,这样就不会超出限制。你必须时刻确保当前用户享受到优质的服务。同样,这做法也约束了某些滥用email的行为,举例来说,这样发垃圾邮件的人就很难获得1000万个帐户——那样的后果很糟糕。

(more…)

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Livingston:还有哪些新特性是独创的?

Buchheit:对话视图——你打开某个对话,其中的所有邮件会像卡片一样列出来,而不是单独出现。

Livingston:这是你想出来的?

Buchheit:其实有好几个原因。其中之一是,我曾做过Groups,那里同样有归类(threading)。另一个是,我们内部有太多的邮件。
如果没有会话,就会出现这种情况:有人发出了一封邮件,有四个人回复了,五个小时之后还有人在回复,其他人会觉得,“这已经重复谈论过五次了,你还要回复。”
据我们观察,人们费那么大力气管理邮件的原因之一在于,他们尝试把对话归拢到一起。他们把邮件放到同一个文件夹——否则就会忘记,或是放错文件夹,对话就完蛋了,再也没法回复。
大家用各种工具和诀窍来管理会话。为什么不把它们直接归拢到一起呢?后来我们又想到,“我们来把引用他人的邮件内容隐藏起来吧”。因为这样阅读速度更快,而不需要浪费精力。我们同样希望集成IM聊天。做第一版的时候,我们没时间集成那个功能,但是很早的原型中就有聊天功能的,因为我们希望把聊天和email做到一起,这两者是一体的。所以,我们会从聊天的角度来看待email,所以我们给聊天加入email功能,而不是走其他的路。显然,聊天是为谈话服务的——没有人受得了分割成一条条的聊天纪录。所以,谈话视图也是从此而来——有段时间我们甚至把email的格式设定得更像聊天。

(more…)

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Livingston:这么说,你花了一天来做Gmail,而你不知道自己在做的事情的意义——之后呢?

Buchheit:很长时间里就只有我一个人,然后Sanjeef Singh加入进来。但是,在Google更换项目,尤其是那时候的Google更换项目,并不容易。不是说,某一天你就忽然去做一个新的项目了。那时候他正在做企业搜索,所以他还得花很多时间在企业搜索上。过了很久,Sanjeef才把大部分时间用在Gmail上。所以有很长的时间,Gmail的进展非常慢。
开始主要是我,然后是我和Sanjeev,之后另一个家伙Jing Lim也来了。团队的增长非常缓慢。做一个email那样迥然不同于Google传统的东西,这想法人们还是不太确定。

Livingston:你宣布:“这是了不起的东西,我们要发布了”。这是什么时候?

Buchheit:是发布几天以后。这项目很大。有些时候,我们似乎根本不可能完成它。

(more…)

Founders at Work是一本有意思的书,讲述了若干有意思的创业故事,我看得兴起,顺手把访谈Gmail创始人Paul Buchheit的一章翻译出来,给有兴趣的朋友看看。

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Paul Buchheit是Google第23名员工。他创造并领导开发了Google的Web邮件系统,Gmail,该产品引领了当今所谓“Web2.0”的众多特性。除此之外,Buchheit开发了Adsense的第一版原型,Google依靠这个程序在其它网站显示广告。在2000年一次关于公司价值的一次会议上,他提出了现在众所周知的公司信条:不做恶(Don’t be evil)。

尽管Buchheit算不上创始人,但他对Google的贡献,可能比其他许多创始人在创业时的贡献更大。Gmail其实是在Google内部诞生的——这是一个传奇般的项目,起初,它并不是公司的主要业务,只是由一小群人发起,而且,许多人开始并不看好它。

Livingston:讲讲事情的开头吧。Gmail是非正式项目(side project)还是公司指派的任务?

Buchheit:实际上两种因素都有。我很早就在做Email软件,当时大概是1996年,但只是个小项目。但Gmail的想法从来没有实现过。奇怪的是,大概因为一些别的理由,那时候我似乎就想叫它Gmail。这只是凑巧——它并不必然是Gmail的前身,却是我一直在思考的,因为我长久以来就对email不满意。
那时候我在学校念书,还没有hotmail。要看邮件,你得回宿舍。我想,这可真够傻的,我应该能在任何地方检查邮件。所以就想做基于web的邮件。我真的不知道那时候自己在干嘛,因此也没什么结果。我写了点程序,但一直没什么用处,也从来没投入实用。
中间内容就不提了,直接说最后:我到了Google,为Google Groups工作,groups和email不完全一样,但是有关系。等Google Groups的第一代产品差不多完善之后,他们问我,是否愿意开发某种email或是针对个人的产品。这只是一个粗略的意向。他们只是说:“我们觉得这类东西有点意思”。当然,我很高兴干这个。

(more…)

Next Page »