新人入职100天，聊聊自己的经验&教训

这篇文章讲了什么？

如题，本屌入职100天之后的经验和教训，具体包含：

• 对开发的一点感悟。

• 对如何提问的一点见解。

• 对Google开发流程的吐槽。

如果你

• 打算去国外工作。

• 对Google的开发流程感兴趣。

• 想成为一个不错的开发者。

那么请继续阅读。

如果你

• 觉得使用英文单词和缩略语就是装逼（例如此人LRui@和其代表作）。

• 无法忍受一个来自新人的言论。

那么请点击页面左上角或右上角的关闭，谢谢。

正文

区别

不同于一般公司，Google所使用的技术绝大多数是自己的技术，基础类库、文件IO、网络通信，什么都是自己的。尽管开源了不少，但更多的东西是不对外开放，这样就带来两个问题：

1. 缺乏学习资源（由于Google技术大多不对外开放，所以是没有书籍可供参考，只能通过内部教程和文档再加上项目代码，自己去一点点摸索）。

2. 出了问题没法Google（废话，Google会把自己的内部技术放到Google Search上么），也没法Stackoverflow（同前）。

以上两点对于本屌这个曾经的微软系程序员打击极大——至少本屌从来没有在没有书看且没法Google的环境下写代码做项目。

经验&教训

• 使用邮件列表（Mail list），讨论组（Discussion group）。

• 学会如何使用Email提问。

• 如果必要，联系代码原作者。

文档vs代码

Google的文档是非常出色的——无论是设计文档还是API文档都很专业，但前提是你的项目有文档。

比如本屌做第一个项目时，打开项目文档时看到的是这货：

然后问mentor要文档时mentor的表情：

另外的一个问题是同步，你看到的文档很有可能不是最新的：

所以即便按照文档编写代码，也会有一定的几率出错：

1. 没有依照文档，代码有问题。

2. 依照文档，但文档有问题。

3. 文档和代码都有问题。-_-

在被以上可能性痛虐三周之后，本屌终于领悟到凡事都要靠代码这个硬道理，走上了写什么之前都要看三遍代码（文档代码，项目实现代码，项目引用代码）的康庄大道。

经验&教训

• 代码即是文档，引用即是示例代码。

• 文档只是辅助。

提问

看文档读代码并不能解决所有的问题，如果一个任务纠结了15分钟还没有头绪，准备提问吧。

找准提问对象

每个人都有自己擅长的领域，问正确的人正确的问题会极大提高工作效率，反之亦然。

这就要求对身边的同事有一个了解——知道对方擅长什么，不擅长什么。刚刚入职时本屌有一个毛病，就是把所有的问题都倾泻在mentor一人身上——一开始mentor会耐心的解答，但是时间长了就发现他的反应变的越来越慢，后来经Manager提醒才恍然大悟，开始和每个同事交流，并阅读他们的CV以了解他们的经历，提问问题的效率大大增加。

清晰描述上下文和目标，而非实现

提问的首要因素是描述你想做什么（What you want），而不是描述你做了什么（What you've done）——xxx对这个话题有精彩的描述。

比如说在GuiceBerry里如何使用GuiceBerryRule引用Guice注入的对象是一个很蠢的问题，因为：

1. 涉及到了实现。

2. 问题本身就是错误的。

而如何在JUnit下实现一个全局的Pre/Post Method而不使用继承，就是一个不错的问题：

1. 明确的上下文和目标。

2. 逻辑合理，且不涉及任何实现（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群聊，文化背景的缺失加上不同的口音使得交流难上加难。

• 用Blog练习Formal writting，用Reddit上练习Informal speaking。

开发

编程 V.S. 开发

首先说说本屌对编程和开发的理解。

• 编程（Programming）偏向于计算机科学（Computer Science）这一端，涉及到离散数学，数据结构，算法设计，人工智能等等，侧重于计算机，目标在于让计算机完成一个指定的任务。

• 开发（Development）偏向于软件工程（Software Engineering）这一端，涉及到进度管理，软件架构，交互设计等等，侧重于团队，目标在于让团队按时交付可用的软件。

• 学校里侧重编程，公司里侧重开发。

• 编程为开发提供理论基础，开发把编程转化为商业价值。

应届IT屌从学校到公司的最大的转变就是从编程到开发的转变：

1. 一部分人接受转变，从各种项目经验中吸收教训，成为卓越的开发者（Developer，比如DHH）

2. 一部分人拒绝转变，钻研基础理论，成为卓越的研究者（Researcher，比如Wangyin）

3. 至于剩下的——就是真正意义的码农（Code monkey，恕不举例）。

经验&教训

• 本屌的理论基础薄弱+天赋一般，编程这条线路走不通，所以成为一个专业开发者是本屌的目标，也是接下来几年的努力方向。

• 准备这个书单做起。

代码评审

Google对代码质量要求很高，任何提交的代码都需要自备测试，且需要得得到具有代码审查资格的专家开发者的认可，即LGTM（Looks Good To Me）。所以Google写代码大概是这样的：

最惨的当属第一次代码评审

至于本屌的第一次代码评审

不到200行程序，大改四次，小改155处，耗时三周。

搞的本屌感觉此生都不会再爱了 -_-

但代码审查仍然是必须的：

经验&教训

• 团队中编写代码不同于个人程序，需要遵守很多规则和潜规则：大到基本的Coding Style Guideline，小到Project-specific Convention。

• 英语词汇量很重要，不同的词汇会带给代码不同的含义，例如build，create，establish，calculate和compute都表示构建一个对象，但它们的引申义就很不一样。

熟悉关键技术

关键技术，就是自己日常工作所依赖的技术以及工具。使用频率越高，越需要熟练。

本屌在入职头两个月就犯了老毛病——啥都想学，啥都想碰，看这个人说Parserc就去搞，看那个人说Haskell炫就去做，结果连个屁都没搞出来，效率还一落千丈。

直到春节请了两周假自省了下，才发现问题所在：自己仍然在用学校时的方式在公司工作——什么都好奇，什么都想学一把。

但问题在于现在是在工作，有明确的任务和时间点，而且本屌远远做不到游刃有余，这会玩个人拓展不是找事么。

于是春节回去后重新制定了学习目标：

1. 熟练Google的内部工具链，通读这些工具的设计文档，架构文档和使用手册。

2. 熟悉Google的基础类库，阅读文档，做练习，并阅读其实现

3. 熟悉自己项目架构和关键代码。

然后每周除了周六都在折腾上面的一坨。效果很显著——开发效率比之前高了至少一倍，不少问题变的可以独立解决。

经验&教训

• 人的精力是有限的，尤其是工作之后。

• 工作的主线任务是高效完成工作，拓展能力等支线任务等主线任务搞妥了再搞也不迟。

• 学习很重要，但要计算机会成本——不是所有的学习都能带来足够的回报。

• 80/20分配，8成时间学习工作相关内容（这里指直接相关），2成时间学习工作无关内容。

总结

1. 学会用各种方式问正确的人正确的问题。

2. 80%时间熟练工作技术，20%时间个人拓展。

3. 理论+实践，不断迭代，学习如何成为一个卓越的开发者。

此外如果觉得自己水平不错，欢迎站内信我进行内部推荐。

以上。