一直对Google这个牛X公司的内部开发过程很是感兴趣，毕竟像Google Search Engine、Google云计算平台这些伟大产品都是在这个开发过程下缔造出来的。但也许是Google保密工作做的很好，或许人家不是刻意保密，只是 因为工作太忙或人员太低调，没空派人出来宣讲罢了。外界对Google内部的开发流程知之甚少；知道一些，诸如20%项目，也只是皮毛。

终于有一天，Google的三位工程师冒了出来，为我们带来的了一本名为《How Google Tests Software》的小书。我断断续续用了不到一周时间粗略地浏览了一遍这本书，算是对神秘的Google内部开发过程有了初步的了解了。其中有一些思路 还真是值得我后续深入思考，这里仅列出一些让我心有所触的"点"，与大家共享。

书是从Test角度展开的，但Google的Test与我们所熟知的Test还有不同，包括这个过程的角色设置与职责等。下面是从书中摘录的一些语句(有些地方是我总结后的)和观点，再加上我的一些体会。

1、在Google，Software Testing被称作"Engineering Productivity(工程效率)"，既负责开发和测试工具的开发、发布工程，还负责从单元测试(unit level)到探索性测试(exploratory testing)的全过程。
     
      — 在国内，多数公司的Testers只负责测试过程，而且多从功能测试开始，Unit test是开发人员的责任。大部分公司的开发与测试工具都是开发人员设计和实现的，但也有少部分先进的公司有专职的测试工具开发岗。总体来 说，Google内部的"测试人员"角色是与众不同的。

2、"Quality is a development issue, not a testing issue"、
     "At Google, this is exactly our goal: to merge development and testing so that you cannot do one without the other. Build a little and then test it. Build some more and test some more. "  、
     "The reason Google can get by with so few dedicated testers is because developers own quality.If a product breaks in the field, the first point of escalation is the developer who created the problem, not the tester who didn't catch it."
     "Testing must be an unavoidable aspect of development, and the marriage of development and testing is where quality is achieved."

     — 可以看出Google信奉："Developer是质量的owner，是第一责任人；质量应该由开发人员把关；测试是开发过程必不可少的一方面；将开发与 测试融合在一起以获取更高的质量；开发一些，测试一些(迭代的思想)"。而国内多数组织依旧信奉着测试是软件质量的最后保证这一信条，将开发和测试隔离的 很开。
 
3、Google内部开发测试过程的三个角色：software engineer (SWE) 、software engineer in test (SET)和 test engineer (TE)，Google SWEs are feature developers. Google SETs are test developers. Google TEs are user developers.

    — 在Google，似乎没有纯粹的传统意义上的Testers，按照书中所讲，SWE肯定是开发工程师，负责实现产品功能(feature)，而SET，其 实也是开发工程师，用于编写产品的测试Feature，关于测试Feature这个概念很独特，Google认为，产品应该有两种Feature属性，一 种是function feature，一种则是产品的test feature，而SWE和SET则分别focus这两点。SWE和SET共享同一代码库，是开发过程中的Partner。与SWE关注功能 feature不同，SET更加关注产品的可测试性、如何通过测试提升产品质量以及提升测试覆盖率以及产品性能。他们为产品的feature编写测试代 码，从单元测试到后续的各种测试，编写各种工具，并尽量的将测试自动化，提升测试效率。

       而TE这个角色则有些类似传统的Testers，但在Google也有不同。在Google，TE更多是从user角度去探索产品，有的TE会编写大量脚 本代码，模拟user使用产品的各种场景；按照书中的说法："TEs are product experts, quality advisers, and analyzers of risk"。

4、One of the key ways Google achieves good results with fewer testers than many companies is that we rarely attempt to ship a large set of features at once.

    — 显然Google也倾向于增量的迭代开发，这种模式符合Google内部的role设置，同时，这种role设置也更好地促进了增量迭代开发的顺利高效开展。

5、Build the core of a product and release it the moment it is useful to as large a crowd as feasible, and then get their feedback and iterate. This is what we did with Gmail, a product that kept its beta tag for four years.

     Google often builds the minimum useful product as an initial version and then quickly iterates successive versions allowing for internal and user feedback and careful consideration of quality with every small step. Products proceed through canary, development, testing, beta, and release channels before making it to users.

   — 这似乎就是Google著名的"Beta"模式，目前很多互联网企业(特别是startup)均效仿之。

6、Instead of distinguishing between code, integration, and system testing, Google uses the language of small, medium, and large tests, emphasizing scope over form.

    Small tests cover a single unit of code in a completely faked environment. Medium tests cover multiple and interacting units of code in a faked or real environment. Large tests cover any number of units of code in the actual production environment with real and not faked resources.

    The general rule of thumb is to start with a rule of 70/20/10: 70 percent of tests should be small, 20 percent medium,
and 10 percent large.

   — Google内部的测试不是按照代码单元测试、集成测试以及系统测试这些典型的阶段划分的，而是用"small、medium、large、 enormous"这些词汇来描述测试的各个环节，这些词汇也是Google内部的"共同语言"。如何界定这些测试的scope呢？Google内部有一 套共享的测试执行系统，它通过test size来界定不同的test类型。比如：对small tests的要求是每方法(method)的测试执行时间不能超过100ms，如果1分钟仍然执行不完，则将被kill掉。

7、Keeping it simple and uniform is a specific goal of the Google platform: a common Linux distribution for engineering workstations and production deployment machines; a centrally managed set of common, core libraries; a common source,
build, and test infrastructure; a single compiler for each core programming language; language independent, common build specification; and a culture that respects and rewards the maintenance of these shared resources.

   — 在Google内部一切都是"整齐划一"的，大大降低了各种人员在熟悉、学习和使用过程中的工作量。可以看出，Google为了提升内部开发效率，真是无 所不用其极啊。另外Google内部这套完整的强大的基础设施工具、库、语言以及流程支撑想必也让大家垂涎三尺吧。

8、There is no set rule at Google for when SETs engage in a project, as there are no set rules for establishing when projects become “real.” A common scenario for new project creation is that some informal 20 percent effort takes a life of its own as an actual Google-branded product. Gmail and Chrome OS are both projects that started out as ideas that were not formally sanctioned by Google but overtime grew into shipping products with teams of developers and testers working on them.

No project gets testing resources as some right of its existence. The onus is on the development teams to solicit help from testers and convince them that their project is exciting and full of potential.

  — 这两段话既描述了SETs进入项目的时机，同时也从侧面反映出了Google内部产品的初期形成机制。在这种机制下，一些著名产品诸如Gmail、 Chrome等诞生了。个人很是认同这种自底向上的产品"产生机制"，有利于员工创造力的充分展现。其实退一步来说，我们不一定非要公司明确规定设置 20%个人时间，只是我们在平时工作中主动去发现、去分析、思考和总结，我们一样可以"创造"出一些用于改善我们工作和生活的工具或产品，这些"成果"在 我们的日常工作中使用，逐渐被大家所接受，甚至于发展演化成熟，形成一个可盈利的产品或是贡献给开源社区，不是一样很好么。感觉国内的很多互联网公司里面 的一些同行正在做这些事情。

9、This is the convention at Google: Make the common case fast.

  — 这显然已经上升到了哲学的层次，不仅对开发测试过程的效率改进有着指导意义，对软件自身的调优也是一样富有价值。甚至于对我们的日常生活也是有帮助的。

10、Designs that seek to automate everything end-to-end all in one master test suite are generally a mistake. The larger an automation effort is, the harder it is to maintain and the more brittle it becomes as the system evolves. It’s the smaller, more special purpose automation that creates useful infrastructure and that attracts the most SWEs to write tests.

        Overinvesting in end-to-end automation often ties you to a product’s specific design.

  –  这又是Google内部对自动化测试的一种中肯的实用的理解。我们要自动化，但要掌握方法，不要大而全，要小且精，吸引SWE自己去写测试代码。过分追求全闭环的自动化测试会将你与一个产品的细节间建立依赖。

11、Google centers its development process around code reviews. There is far more fanfare about reviewing code than there is about writing it.
      
       These pre-submit rules cover simple things such as adherence to the Google coding style guide and more involved things such as ensuring that every existing test associated with the CL has been executed (the rule is that all tests must pass).

  — Google打造了一个以代码评审为中心的开发过程，建立了一套完整的日常开发流程以及评审流程。并通过一套完整的工具平台在代码提交评审前对代码进行各种自动化检查，让评审过程更加focus关键业务逻辑，而不是语法之类的细节。

12、Test Runtime Requirements
   – Each test must be independent from other tests so that tests can be executed in any order.
   – Tests must not have any persistent side effects. They must leave their environment exactly in the state when it started.

  — 这里点明测试执行的原则：测试case间无依赖，可任意顺序执行；测试执行应遵循"童子军"纪律：测试执行结束后，将环境恢复到测试起始状态。

13、带认证的测试(Test Certified)

  — Google内部建立了类似竞赛似的规则，对每个项目的测试水平进行认证，分为几个级别：从TC level1到TC level5。对于每个级别都有明确的指标，甚至是明确的达标数字，比如总测试覆盖率，各种类型(比如small)测试的覆盖率等。在每个项目的首页都会 看到该项目的认证级别。这种规则将促使项目SWE和SET不断地改善测试，来提升测试认证水平，间接地提升了产品的质量。

2011年我的确读了不少书，掐指算来纸版和电子版加在一起近50本，其中以技术类居多，但其他方面的也有一些。这里列出来做个简单回顾。

一、技术类
· 《你必须知道的495个C语言问题》
早在这本书出版前，其译者已经在网上完成了C FAQs的翻译(在这里)。这本书是基于最新C FAQs做了重新整理(包含C99)。虽说是最新，但因C语言近几年来变化很小，内容与之前译者在网上公开的那个免费版本相差不多。这本书适应面很广，初学者可以从中了解到很多谭氏教程中没有的东西；有经验的C程序员可以把它当成一本手册，需要时翻看。对于那些很在乎C语言细节的程序员来说，翻看一遍也未尝不可。

· 《The New C Standard – An Economic and Cultural Commentary》
这本书的作者真是牛X的一塌糊涂。整本书居然是对C99规范的逐句解释，而且写成了一部1600多页的大砖头。这本书应该未正式出版，我看的是作者在网上放出的免费电子版。如果你痴迷于C语言规范的细节，这本书是一本不可多得的辅助资料。

· 《C和C++安全编码》
Cert C/C++安全编码经验的浓缩版，读一遍的确可以提高一些编码过程中的安全意识。

· 《Practical Common Lisp》
Peter Seibel编写的一本荣获Jolt大奖的Common Lisp入门书。你在这里可以看到这本书的免费电子版，其中文版名为《实用Common Lisp编程》，现在在我的书架上也躺着一本，我还没抽出时间来看。如果你是Common Lisp初学者，这本书是不二的首选。

· 《ANSI Common Lisp》
Lisp语言的著名吹鼓手Paul Graham的大作，成书于Common Lisp标准化之际，是一本不错的Common Lisp入门的辅助资料。个人认为将《Practical Common Lisp》与此书结合在一起来学习，会加深你对Common Lisp的理解。

· 《Haskell – The Craft of Funcitonal Programming 2nd》
这是一本比《Programming in Haskell》更适合作为函数式编程语言入门的书。书中第一章对函数式编程基本概念的讲解很是到位，并且这本书已经被译成了中文，书名为《Haskell函数程序设计艺术》，在网上可以免费下载到。

· 《Seven Languages in Seven Weeks》
估计大家都见过《21天学会X语言》这样的编程语言教程。21天学会某种编程语言已经有些差强人意了，但这本书更狠 – 书名的直译是"七周学会七门语言"，但显然本书的目标不是这样的。作者的原意是希望读者通过阅读本书了解更多的新兴编程语言以及编程范式，改变编程思维，另外通过本书的阅读可以初步掌握各种语言，并且对语言的掌握程度不仅仅是"Hello World"这一层次。今年年初与其他人合译了此书，也是在那时将这本书通读了一遍。我负责翻译Prolog、Scala和Haskell三个章节。在书中作者将每一门语言比作成一个电影中的人物，使得内容更加生动形象(但翻译起来就没那么容易了^_^)。特别值得一提的是：该书还荣获了今年的Jolt大奖，由此可见业界对该书的认可。

· 《Python参考手册(第四版)》
像Python这样的动态编程语言，一直以极高的开发效率著称，这也是我今年学习和使用Python的一个原因，Python强大的标准库可以帮我快速实现一些想法(buildc就是用Python编写的)。《Python参考手册》这本书并不适合作语言入门之用，里面对语言细节的讲解很少，其内容更多适用于工程参考，包括库函数使用、打包、发布等，这正是当时我所需要的。

· 《持续集成》和《持续交付》
持续集成已经是存在已久的一个最佳实践了。《持续集成》一书对这方面内容做了极其系统的讲解；持续交付将持续集成的概念做了进一步延伸，将软件开发的前段（设计、编码、单元测试）与后段（功能测试、压力测试、发布、部署、验收测试）衔接在一起，形成了一个整体，并通过自动化手段实现了这一概念。在我看来《持续交付》一书更像是一本cookbook，作者将自己实施持续交付过程中采用的方案以及遇到的问题都详实地记录在书中，分享给大家。这本书获得了今年的Jolt技术图书类最高奖，很是值得一读。

· 《深入理解计算机系统 2nd》
本书的第一版是在大学毕业后不久读的，当时真有一种相见恨晚的感觉，读完后战斗力陡增。若干年后第二版的中文版终于出炉了，我又迫不及待地买下，并通读了一遍。这本书究竟咋样，从我豆瓣上给的评语可以看出："如果只允许我为程序员们推荐一本书，那么我会毫不犹豫的将这本csapp推荐给大家。太经典了！"

· 《Binary Hacks》和《Debug Hacks》
讨厌日本人，但有些时候你的确还得向日本人学习，这两本书都是由日本程序员执笔的，而且内容都是有关系统编程以及OS内核编程和调试的，内容比较深，需要你静下心来细心体会，国内程序员往往比较浮躁，愿意做底层技术的很少，坚持下来的就更少了，这方面日本程序员却是我们的典范。有关系统级编程和调试经验和技巧的资料在市面上比较少了，这也凸显了这两本书的价值。

· 《A Bug Hunter's Diary》
这本书只是粗略的浏览了一些，书里的案例实在看不下去，总觉的Debug这事儿只有自己亲手去做才能有所得，就像看《盗墓笔记》一样，看完后你依旧不会倒斗，只有亲自倒一次斗才能学到真本事。

· 《Linux系统编程》
知名Linux内核维护者Robert Love的作品，结合底层原理的机制讲解是本书一大特色，但总体比较平淡，有些地方更像是函数使用手册，建议有经验的程序员快速浏览一遍即可。

· 《Linux系统管理技术手册》
简直就是一本Linux系统管理的大百科全书，内容涵盖各种主流Linux发行版，如RHEL、Debian、OpenSuse、Ubuntu等，极其适合放在抽屉里随时翻阅，我就是这么做的。

· 《Pragmatic Guide to Git》和《Pro Git》
前者适合Git入门，后者适合Git进阶。一个版本控制工具，没有什么好说的。对于Git学习的建议是：要领悟Git背后的思想，另外不要将Git命令的含义与svn等传统版本控制工具的命令混淆，Git命令需全新认知。

· 《软件研发之道》
典型的"新瓶装老酒"，该书早在N年前就出过一中译版，名为《微软团队 – 成功秘诀》。如果你看过后者，你大可不必购买此书。不过如果你没看过这本书，那么还是建议看看，虽说书中讲的是微软当年Visual C++团队的事情，但读后你会发现其中的思想至今仍极具价值。

· 《编程之道》
这是一本奇书，一本悬在空中的书，全书通读完后，你可能依然不知作者所云，但你的内心却已被作者的思想洗礼。

· 《编程匠艺》
如果你认为《代码大全2nd》是好书，那么你也会喜欢这本书，它们是一类的。

· 《大话设计模式》
这类书的目标都是意图将晦涩难懂的《Design Pattern》一书通俗化。但一般看这类书的时候，身旁还要放上一本《Design Pattern》，随时翻阅查证。今年在考量用C实现Pattern时顺便读完了这本书，总体来说算是国内讲解DP比较优秀的一本了。

· 《企业应用架构模式》
Martin Fowler在2003年的作品，也是当年Jolt效率大奖获得者。当时也是企业应用架构蓬勃发展的时期 – J2EE大行其道，轻量级框架方兴未艾。作者将当时进行企业应用架构设计一些经验模式进行了详尽的总结并写成此书。在企业应用设计方面，我了解甚少，这也是今年阅读此书的一个主要原因。

· 《走出软件作坊》
为数不多的国内IT企业技术管理者的经验之谈，很多人在书中会找到自己的影子。

· 《黑客与画家》
Paul Graham的又一部大作，与之前的那本不同，这本更像是Paul的散文集，看完后是否能受益，全看你的悟性了。

· 《构建高性能Web站点》
我不是搞Web开发的，但此书前三章对Web站点性能影响因素的分析还是让我受益匪浅的。

· 《程序设计语言原理》
从China-pub淘来的一本特价书，但读了之后我感觉即使是原价买来也是很划算的。

· 《程序开发心理学》
温伯格的经典之作。由于原著成书较早，经过几十年很多思想其实早已经通过其他渠道灌输到我们的大脑中了，但越是这样我们越是惊叹于温大牛惊人的预见力。要知道这本书最早成书于1971年。

· 《算法技术手册》
今年读的唯一算法类书籍，这本书不像《算法导论》那样钻理论牛角尖，也不像《程序员实用算法》那样着重于算法的实现，它旨在赋予你精确选择算法的能力，以帮助你精确高效地解决面临的问题。

二、社科类
· 《赢》
杰克.韦尔奇退休后的总结之作。记得上次陪LP参加桩考，我用了大半天时间在我的Bambook上把这本书浏览了一遍。不过在我这个层次上尚无法理解杰克全部之言。这本书对于不同层次的人会有不同的价值。它就是那种需要你在不同时期反复多次阅读的一本书。也许若干年后再读此书，我会有更深刻的认识。

· 《浪潮之巅》
今年我读到的最震撼之作。之前吴军在Google黑板报上连载时我并未太过在意，这次系统地通读一遍后，让我眼界大开，从书中学到了许多，同时也激发我想到了许多。

· 《搞定: 无压工作的艺术》(Getting Things Done的中译版)和《时间管理：小强升职记》
前者是GTD时间管理理论的源头，后者则是国内GTD牛人的经验之作。时间管理是今年我的一个重点改进目标，这两本书给了我很大帮助。

· 《哪来的天才》
这本书向我们阐述了一个观点：刻意练习是天才的一个必要条件。如果你不认同，那么打开这本书，慢慢看吧。

· 《把时间当作朋友》
原新东方英语教师李笑来的作品，很难想象他这样的职业能写出这种题材的书。

· 《重来》
来自一个创业公司创业者们的颠覆性观点。

· 《少有人走的路》
感觉没有外界宣传的那么好，也许我还没有悟到。

· 《卓有成效的管理者》
管理学大师的作品总是值得一读的，虽然你很可能已经从其他场合学到过其中的思想。

三、传记类
· 《活着就为改变世界》和《史蒂夫·乔布斯传》
看《活着就为改变世界》时，乔布斯还活着；后来乔布斯去逝了，我拿到了《史蒂夫·乔布斯传》。感谢京东的促销活动，让我以超低的价格买到乔帮主留给世人的这最后的礼物。两本书都告诉我一个事实：乔布斯的确与众不同，但讨厌他、憎恨他的人也大有人在。

· 《世界因你不同》
以前看过李开复的《做最好的自己》，对李开复有些了解，所以读这本传记时也就走马观花了。

· 《留德十年》和《牛棚杂忆》
一直很想知道季羡林为何被称为国学大师，通过回忆录是了解这个大师的一个很好的途径。

四、小说类

· 《盗墓笔记系列》
这类题材的书籍总是吸引人的眼球，就如作者所说的“盗墓代表着人类一种最原始的欲望，求得财富和探询死亡，这种刺激，恐怕是人就无法避免的"。不能去倒斗，看看别人如何倒斗也能满足一些欲望^_^。

· 《三体》
慕名而读，名不虚传。作者超凡的想象力让人不能不折服，至少第一部是如此。

· 《高地》
今年看的唯一一部军旅题材小说，在部门旅游来回的途中把这部小说看完，情节跌宕，情感细腻，值得一看。

五、其他类
· 《准备去美国读书》
为了了解美国教育是什么样子的，从图书馆借阅的，如果你和我有同样的目的，这本书还是可以满足需求的。

· 《实用IT英语》
简直就是为IT人士量身定做的外语书，着重培养"英语思维"的形成，感觉书的内容也比较新颖。

很多朋友可能会问：工作这么忙，家庭生活琐事那么多，哪里还有什么时间读书呢？我又何尝不忙呢，每天8小时工作，周末还要陪果果。这里的关键还是要有坚定的读书信念，养成良好读书习惯，就好比一日三餐那样，非读不可。另外还要不断提高读书效率，充分利用零散的时间。现在市面上电纸书(比如kindle、bambook)越来越成熟，便携性也越来越好，你可以把坐车、等车以及闲暇休息这些零散时间充分利用起来，一年下来你挤出来的时间也是惊人的。