深入敌后:iOS开发者在Google的三个月

英文原文:Chris Hulbert,编译:威锋网

近日,Chris Hulbert 在科技博客Splinter Software上发表了一篇日志,与读者们分享了他作为 iOS 开发者在Google工作的3个月经历。虽然时间并不长,但是他也分享了一些在Google的工作经验,值得借鉴。

以下是Chris Hulbert文章的主要内容:

作为一名 iOS 开发者,我最近终止了和Google(Sydney)的合同,我的工作是开发Google Maps Coordinate应用。在忘记这段经历之前,我想和大家分享一些体验和经历。不过,因为时间不长,所以不会有什么大爆料。

在Google工作的 iOS 开发者

我那些 iOS 开发者朋友听到这个消息的时候,第一个反应都是“iOS?在Google?这不是像在敌人战线上工作一样吗?”是的,在Google,你不会见到一部 iPhone,除了 iOS 团队的测试用机之外。在那里,每个人都很喜爱自己的安卓手机,我猜这也许是因为他们每年都能得到一部免费Nexus 手机。由于我在今年圣诞节前就离开了,我不知道今年圣诞他们得到了什么。

那里的人有一些反 iOS 情绪,你会常常听到他们取笑 Objectiv-C 奇怪的语法或者苹果其他的缺陷(比如地图)……但另一方面,在Google的 iOS 开发者其实要比你想象的多,如果你愿意,可以在那里干出一番事业。

Google有一个很好的小内部社团,如果你是在山景城(Google总部)的话,你需要做出很好的应用,但是Sydney这边要求没有那么高。但是,如果你是一名 iOS 开发者,离山景城很近的话,那离库比蒂诺也不远了。

工作流程

那里的工作流程是怎样的?每一个人都有一份任务单,而每一个任务又有分支,当你的任务完成之后便可以将代码提交等待审查,如果获得“Readability”或者“Owner”认可的话,那就代表代码被接受。Readability 是一个相关语言通过的内部认证,而 Owner 则表示代码在某个特定源分支上获得了认可。最好的情况是你的代码得到了认可,然后可以往更高一级发展。

但是,最经常的情况是,你的代码总有这样那样的错误,或者是风格上的违和需要修改。评审人员会在评论系统中给出评论意见,指出需要修改的地方。Google对代码风格的要求很严格,比如错误的空格或者行数距离宽于 80 个字符这些小细节都会被纠出来,另外,评审人员还纠出许多基本法则运算错误,或者是给出更好的语言组织建议。

这种工作方式的一个好处就是代码能够写的更好,但是代价很高,而且也有一些缺点——导致工作进程慢。你完成了工作,提交等待审核,你的代码很有可能在快下班的时候才轮到审核,如果这时候你要修改的话,你要等到第二天审核结束,评论回馈的之后才能再修改,然后再提交等待审核。有时候碰上审查人员外出开会,没有时间审查你新提交的代码,我没有听说过有哪一个代码能够在一个星期之内通过审核的。

如果你的工作是连续性的,分 A、B 阶段,那你要先等A通过审核许可之后才能进行 B 工作,这拖了不少时间。所以我都是错开工作的,比如我提交了 A 之后,我去做另外一个与 A 工作没有任何联系的任务,等到 A 通过之后,再接着做 B 任务。通常情况下,我都有 3 到 4 个不同的工作提交上去等待审核,最高的一次记录是 6 个工作任务。我的这种工作方式虽然省下了时间,但是很费力,因为一个人很难将精力从这个任务抽到另外一个不相关的任务当中。

虽然这种工作流程有点令人沮丧,但是慢工出细活,Google好代码的代价是更多、更慢的开发者,对于这个代价,我自己也没有什么更好的建议。

设计

作为一名 iOS 开发者,我习惯“设计优先”原则,先是一些人设计出应用,然后 UX(用户体验)工作人员做出线框,然后设计师模拟出他们想要的样子,最后再交给我们开发者。

这样的设计方式看起来挺好,用户体验工作人员知道制作出更好的用户界面,而设计师知道如何让应用更可行。但是,Google似乎并不是很看重设计,安卓并不漂亮的UI就是一个很好的说明。

总的来说,在Google(Sydney)工作时一次很不错的体验,而且在那期间我还胖了不少,我唯一感到遗憾的是,由于不可控的家庭因素不得不提前终止了合同。

深入敌后:iOS开发者在Google的三个月

CSDN UPDATE:

iPhone开发

值得一提的是,我们在Google开发iOS应用有几点很有趣的地方:

1.如果你不能合并它,你就不能使用。解决过xib文件上的合并冲突吗?我也没有。所以xib不被允许的。这很对我的胃口——我一直不喜欢xib、story board,这些都是垃圾。

2..pbxproj 文件一样会出现合并冲突——因此也不会被签入(check)到源控制中,Google使用GYP,是他们自己研发的开源工具,效果非常好。可惜GYP的文档非常少,而且无法执行某些项目的配置(例如:per-file -fno-objc-arc)。

3.测试覆盖率非常重要,Google的指标在90%之上,我们使用CoverStory工具来检测这一指标。单元测试(使用Google封装的SenTest)和集成测试(使用KIF)都少不了,但只有单元测试计入覆盖率。

4.实例变量都在头文件中按字母排序,所以dealloc时也会这样样,更易于检查内存泄漏。但我认为他们在所有新项目中都开始使用ARC,至少我后面那人就是这样……好像是一个大项目……

 

收藏 2 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 值得一提的是,我们在Google开发iOS应用有几点很有趣的地方:
    1.如果你不能合并它,你就不能使用。解决过xib文件上的合并冲突吗?我也没有。所以xib不被允许的。这很对我的胃口——我一直不喜欢xib、story board,这些都是垃圾。

    哈哈哈 (呲牙)

  • Edward Shen   2014/02/07

    Google的开发方式相当扯淡嘛! 这样玩的话,一个工程师只能发挥10%的效率。

跳到底部
返回顶部