首页 > 程序开发 > 移动开发 > IOS >

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

2013-01-27

以下是Chris Hulbert文章的主要内容:作为一名 iOS 开发者,我最近终止了和Google(Sydney)的合同,我的工作是开发Google Maps Coordinate应用。在忘记这段经历之前,我想和大家分享一些体验和经历。不过,...

以下是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,至少我后面那人就是这样……好像是一个大项目……
相关文章
最新文章
热点推荐