保持干净(2)

  随着Google的成长,并不是所有人都认同他们的代码需要证明或者他们有责任检查其他人的工作。克雷格回忆时说:“我们添加了一个程序,可以阻止没经过检验就提交的代码,不过要是你撒谎的话,这个程序也没办法。”

  为了应付这个程序,大家会对代码进行粗略的检验。克雷格告诉我说:“我发出了庞大的代码,他们又发了回来并说‘看起来不错’。我觉着他们不应该这么简单地评价我发出的代码。”

  雇员们开始检验代码时,克雷格也亲自检验他们的代码,并反复告诫他们要形成编程的合作系统。一些人对此嗤之以鼻。克雷格说:“保罗-布切特对此痛恨不已,诺阿姆对此也是不以为然。但保罗最后还是独自做了许多代码检验的事情,并且力挺这种方法论。诺阿姆认为这就是在浪费时间—他像拉里和谢尔盖一样,是个研发人员。他会说:‘我们检验这些代码的时间比编写的时间还要多—这是怎么充分利用时间的?’”

  赛恩吉-杰姆瓦特对于代码检验并不反感。在他原来工作的研究机构,一般会认为适当监视他人的行为有侵犯隐私之嫌。尽管如此,他却马上从一个睿智检验者的角度发现了代码检验的价值。代码检验加强了思想的交叉碰撞,同时也提高了可接受的标准。赛恩吉告诉过我说:“极而言之,你可以说,‘好吧,确保遵守风格指南就行’,这样的标准是非常机械的。我的要求则不同。你需要相信代码真正合理可行,不会出现极端状况或问题—并且简单易懂。我相信,这样的话效果会很好。”

  本-戈梅斯对赛恩吉的代码和增加代码库的方法十分推崇。戈梅斯对我说:“这为今后的编码设定了基调。”不过,他也笑话赛恩吉的标准并不合理。

  戈梅斯回忆赛恩吉时说:“他对我不会正确使用空格的事实无法忍受。在一次代码检验中,他把光标放在最底下,然后说,‘这里有空格。为什么会有空格?’”

  我向赛恩吉问起这件事时,他忍不住哈哈大笑。

  “我那么做只是想让本紧张起来。我希望当几年后再看那些代码时,即使已经几乎忘了我们编程时是怎么想的,也仍然看得懂。这些格式错误可能会造成问题,所以得改。”

  由于乌尔斯激励工程师团队把复杂的问题分解成可解决的小部分,代码检验对于确保重装时各部分的匹配至关重要。整个系统给予工程师们独立的空间,但是也会限制他们不离代码库统一标准太远。

  多年之后,乌尔斯说过:“从根本上说,一个好的团队会制造问题也会解决问题。如果团队不适合做这项工作的话,他们会犯一些小错误破坏解决方案,最后你根本不知道犯了什么错误—但结果就是不对。你需要对每一天每一周进行控制。一个新手会认为这些都微不足道,但是他们并没意识到累积的效果。因此过了几个月后,你会在没意识到犯错的情况下彻底破坏解决方案。这都是一系列小事惹的祸。”

本文摘自《Google传》


保持干净(2)   Google的企业宗旨“不作恶”是如何来的?为什么拉里和谢尔盖有能力吸引硅谷中首屈一指的风险投资公司支持他们?浏览器工具栏竞争中,微软和Google掀起了秘密决战,最后胜败如何?当微软公司宣称“我们要么买下你们,要么就灭掉你们!”时,Google又是如何逃过一劫?
  这是一部最详细、最全面、最真实地记录一家伟大的互联网公司发展历程的书。在这本书中,作者提到拉里R26;佩奇是个很强势的家伙,他火热的激情要帮助全世界不再浪费时间。拉里喜欢削减一切不必要的开销,不过在成本控制方面,不折不扣地把节俭才智发挥到极致的还是谢尔盖。在意大利米兰,他为了节省50美元,而不愿意选择乘坐出租车。