英文原文：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）工作時一次很不錯的體驗，而且在那期間我還胖了不少，我唯一感到遺憾的是，由於不可控的家庭因素不得不提前終止了合同。
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，至少我後面那人就是這樣……好像是一個大專案……