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

这篇文章讲了什么?

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

  • 对开发的一点感悟。

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

  • 对Google开发流程的吐槽。

如果你

  • 打算去国外工作。

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

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

那么请继续阅读。

如果你

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

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

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

正文

区别

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

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

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

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

经验&教训

  • 使用邮件列表(Mail list),讨论组(Discussion group)。

  • 学会如何使用Email提问。

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

文档vs代码

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

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

WTF Documentation

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

Ask for documentation

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

Inconsistency

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

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

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

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

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

Code is Document

经验&教训

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

  • 文档只是辅助。

左手只是辅助

提问

看文档读代码并不能解决所有的问题,如果一个任务纠结了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写代码大概是这样的:

Coding@Google

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

First Code Review

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

My Code Review

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

Cry

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

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

Why code review is needed

经验&教训

  • 团队中编写代码不同于个人程序,需要遵守很多规则和潜规则:大到基本的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. 理论+实践,不断迭代,学习如何成为一个卓越的开发者。

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

以上。

posted @ 2014-02-23 23:30  _Luc_  阅读(12212)  评论(21编辑  收藏