这篇文章讲了什么？
如题，本屌入职100天之后的经验和教训，具体包含：
对开发的一点感悟。
对如何提问的一点见解。
对Google开发流程的吐槽。
如果你
打算去国外工作。
对Google的开发流程感兴趣。
想成为一个不错的开发者。
那么请继续阅读。
如果你
那么请点击页面左上角或右上角的关闭，谢谢。
正文
区别
不同于一般公司，Google所使用的技术绝大多数是自己的技术，基础类库、文件IO、网络通信，什么都是自己的。尽管开源了不少，但更多的东西是不对外开放，这样就带来两个问题：
缺乏学习资源（由于Google技术大多不对外开放，所以是没有书籍可供参考，只能通过内部教程和文档再加上项目代码，自己去一点点摸索）。
出了问题没法Google（废话，Google会把自己的内部技术放到Google Search上么），也没法*（同前）。
以上两点对于本屌这个曾经的微软系程序员打击极大——至少本屌从来没有在没有书看且没法Google的环境下写代码做项目。
经验&教训
使用邮件列表（Mail list），讨论组（Discussion group）。
学会如何使用Email提问。
如果必要，联系代码原作者。
文档vs代码
Google的文档是非常出色的——无论是设计文档还是API文档都很专业，但前提是你的项目有文档。
比如本屌做第一个项目时，打开项目文档时看到的是这货：
然后问mentor要文档时mentor的表情：
另外的一个问题是同步，你看到的文档很有可能不是最新的：
所以即便按照文档编写代码，也会有一定的几率出错：
没有依照文档，代码有问题。
依照文档，但文档有问题。
文档和代码都有问题。-_-
在被以上可能性痛虐三周之后，本屌终于领悟到凡事都要靠代码这个硬道理，走上了写什么之前都要看三遍代码（文档代码，项目实现代码，项目引用代码）的康庄大道。
经验&教训
代码即是文档，引用即是示例代码。
文档只是辅助。
提问
看文档读代码并不能解决所有的问题，如果一个任务纠结了15分钟还没有头绪，准备提问吧。
找准提问对象
每个人都有自己擅长的领域，问正确的人正确的问题会极大提高工作效率，反之亦然。
这就要求对身边的同事有一个了解——知道对方擅长什么，不擅长什么。刚刚入职时本屌有一个毛病，就是把所有的问题都倾泻在mentor一人身上——一开始mentor会耐心的解答，但是时间长了就发现他的反应变的越来越慢，后来经Manager提醒才恍然大悟，开始和每个同事交流，并阅读他们的CV以了解他们的经历，提问问题的效率大大增加。
清晰描述上下文和目标，而非实现
提问的首要因素是描述你想做什么（What you want），而不是描述你做了什么（What you've done）——xxx对这个话题有精彩的描述。
比如说在GuiceBerry里如何使用GuiceBerryRule引用Guice注入的对象是一个很蠢的问题，因为：
涉及到了实现。
问题本身就是错误的。
而如何在JUnit下实现一个全局的Pre/Post Method而不使用继承，就是一个不错的问题：
明确的上下文和目标。
逻辑合理，且不涉及任何实现（Implementation）。
寻找Pointer，而非Value
多数情况下解决问题需要的只是一个链接（Pointer），而并不需要整个方案（Value），好比C语言为了提高效率传递Pointer而非Value，Caller给你一个Pointer，Dereference的任务交给Callee即可。
另一个比方是问路，一个正常的问路人绝壁不会要求指路人把他带到目的地去——一条正确的路线或一份清晰的地图就足够。
经验&教训
问正确的人正确的问题。
寻求Pointer，而非Value。
交流
话题
尽管UK充斥着中国制造，但中国对于他们来说仍然是一个神秘的国度，所以初次和外国人聊天聊China是个不错的话题，Food、Kungfu和Weather都是不错的选择。
然而不能总聊China——不停地说自己的国家谁都会烦，这时就需要去了解他们的文化，除了技术以外，本屌比较喜欢聊新闻、电影和电视剧。
活动
融入国外生活的另一个方式是参加他们的活动——每次室内攀岩、桌球或是乒乓本屌都不会落下，算是乒乓外交吧。
比较有趣的是他们都认为中国人个个都是乒乓高手，尽管本屌的水平并不怎么样。
此外在国外Pub和Party也是重要的社交场合，不过电影里看到的不太一样。前者是几个人边喝酒边扯淡，后者是一堆人边喝酒边扯淡，由于本屌的英语水平实在拙计，所以这种场合一般只有练听力的份 -_-
经验&教训
对于天性闷骚的天朝IT屌而言，运动是一项很好的融于外国人圈子的方式。
和外国人交流的难点在不在于1v1私聊，而在于1vN群聊，文化背景的缺失加上不同的口音使得交流难上加难。
开发
编程 V.S. 开发
首先说说本屌对编程和开发的理解。
编程（Programming）偏向于计算机科学（Computer Science）这一端，涉及到离散数学，数据结构，算法设计，人工智能等等，侧重于计算机，目标在于让计算机完成一个指定的任务。
开发（Development）偏向于软件工程（Software Engineering）这一端，涉及到进度管理，软件架构，交互设计等等，侧重于团队，目标在于让团队按时交付可用的软件。
学校里侧重编程，公司里侧重开发。
编程为开发提供理论基础，开发把编程转化为商业价值。
应届IT屌从学校到公司的最大的转变就是从编程到开发的转变：
一部分人接受转变，从各种项目经验中吸收教训，成为卓越的开发者（Developer，比如DHH）
一部分人拒绝转变，钻研基础理论，成为卓越的研究者（Researcher，比如Wangyin）
至于剩下的——就是真正意义的码农（Code monkey，恕不举例）。
经验&教训
本屌的理论基础薄弱+天赋一般，编程这条线路走不通，所以成为一个专业开发者是本屌的目标，也是接下来几年的努力方向。
准备这个书单做起。
代码评审
Google对代码质量要求很高，任何提交的代码都需要自备测试，且需要得得到具有代码审查资格的专家开发者的认可，即LGTM（Looks Good To Me）。所以Google写代码大概是这样的：
最惨的当属第一次代码评审
至于本屌的第一次代码评审
不到200行程序，大改四次，小改155处，耗时三周。
搞的本屌感觉此生都不会再爱了 -_-
但代码审查仍然是必须的：
经验&教训
团队中编写代码不同于个人程序，需要遵守很多规则和潜规则：大到基本的Coding Style Guideline，小到Project-specific Convention。
英语词汇量很重要，不同的词汇会带给代码不同的含义，例如build，create，establish，calculate和compute都表示构建一个对象，但它们的引申义就很不一样。
熟悉关键技术
关键技术，就是自己日常工作所依赖的技术以及工具。使用频率越高，越需要熟练。
本屌在入职头两个月就犯了老毛病——啥都想学，啥都想碰，看这个人说Parserc就去搞，看那个人说Haskell炫就去做，结果连个屁都没搞出来，效率还一落千丈。
直到春节请了两周假自省了下，才发现问题所在：自己仍然在用学校时的方式在公司工作——什么都好奇，什么都想学一把。
但问题在于现在是在工作，有明确的任务和时间点，而且本屌远远做不到游刃有余，这会玩个人拓展不是找事么。
于是春节回去后重新制定了学习目标：
熟练Google的内部工具链，通读这些工具的设计文档，架构文档和使用手册。
熟悉Google的基础类库，阅读文档，做练习，并阅读其实现
熟悉自己项目架构和关键代码。
然后每周除了周六都在折腾上面的一坨。效果很显著——开发效率比之前高了至少一倍，不少问题变的可以独立解决。
经验&教训
人的精力是有限的，尤其是工作之后。
工作的主线任务是高效完成工作，拓展能力等支线任务等主线任务搞妥了再搞也不迟。
学习很重要，但要计算机会成本——不是所有的学习都能带来足够的回报。
80/20分配，8成时间学习工作相关内容（这里指直接相关），2成时间学习工作无关内容。
总结
学会用各种方式问正确的人正确的问题。
80%时间熟练工作技术，20%时间个人拓展。
理论+实践，不断迭代，学习如何成为一个卓越的开发者。
此外如果觉得自己水平不错，欢迎站内信我进行内部推荐。
以上。