說一下谷歌的開發流程

首先，某 G 大部分產品線都不區分前端工程師和後端工程師，一我的須要用從前到後都負責開發，儘管這幾年彷佛有變化，能看到專門的Front End 職位了，但應該是不多數產品線的作法。

 

N 年前有人去 G 面試過，和他閒聊後瞭解到某 G 要求應聘者必須至少要會 C++ 和 Java 中的一種，只會 Python/PHP 是不夠的，要是隻懂 JS 就更不行了。這個信息很關鍵，能用來解釋一些內部現象，後面我會提到。

 

我我的認爲前端工程師確實應該瞭解基本的後端知識，某 B 公司之前不少前端工程師都只負責模板（好比 Smarty）開發，這致使一個很嚴重的問題，那就是前端工程師每每不知道如何搭建環境，開發時須要依賴後端工程師提供環境和數據，嚴重影響了開發效率，這也是爲何 FIS 還內嵌了本地服務功能。

 

另外國內有公司還對前端工程師作進一步細分，按照職能分爲寫 HTML/CSS 和 JS 的，對於我所屬的團隊，我我的並不贊同這種作法，由於 HTML 和 JS 是密切相關的，這樣分工將不利於代碼管理與優化，尤爲是交互複雜的頁面，由於 JS 很依賴 HTML，拆分反而增長溝通成本，但或許在重運營的網站這麼作會更好。

 

代碼管理方法

如下是一些零碎瞭解到的幾點：

 

內部全部人都能看到代碼

 

聽說在 09 年時某國家的 office 有例外（來自『In The Plex』第 6 章，內容比較不和諧，這裏就不展開了）

 

提交代碼須要相關人員的 review

 

這使得某 G 內部工程師能夠很方便地切換項目，不多一我的只負責一個項目

 

代碼只有最新版(trunk)，沒有 release 版本，沒有版本號

 

通常你們喜歡新增接口

若是要修改原有的接口，就必須通知全部使用方，不過由於全部人都能看到全部代碼，因此很容易找到有誰使用

 

據瞭解某 F 也是這樣的

有個代碼的搜索引擎

 

我認爲這種方式比讓工程師寫文檔靠譜多了，由於絕大部分調用這個庫的代碼都是類似的，因此直接給出例子能讓別人更容易上手

 

估計和下線的 Code Search 比較像（好像仍是某高管寫的，不過我忘記在哪看到的了）

 

若是想使用某個基礎庫，最好的方法是搜索使用到這個庫的相關代碼，抄過來

 

代碼依賴是經過全局的方式統一管理的

 

我猜應該很相似 Chromium 中的 GYP，熟悉 node 的同窗能夠理解爲 npm，不過是支持多語言的

 

以前在某 G 工做過的 iOS 工程師也在某篇後來刪除的文章中透露代碼中不放 Xcode 項目文件，而是由工具生成出來（話說這篇文章挺有價值的，惋惜老外不喜歡轉帖，致使如今找不到了）

 

這種依賴管理方式讓人想起某 A 公司（賣書那個，不是賣水果的）內部完善的 SOA 機制，不過某 A 喜歡基於 service 來重用，而某 G 看起來喜歡代碼級別的重用

 

不多使用第三方庫

 

只能選用內部維護的版本，好比相似這個 MySQL

 

會將第三方庫的編譯工具改爲內部的，好比 Chromium 中都改爲 GYP 方便管理

 

聽說想申請用某個新第三方庫須要審覈，週期比較長

 

代碼管理軟件用的 Perforce

 

某 G 直接將這個公司買下了（未確認，但下面那篇論文是在某 G 網站上的，因此我感受消息可靠），Perforce 的員工爲某 G 內部定製了一套代碼管理工具

 

另外我找到一篇 Perforce 的性能優化的論文，這裏面透露了不少 G 公司內部的代碼狀況（發表時間是 2011 年 5 月），如下信息取自這篇論文：

 

這個程序用了 17 年，有 2 千萬次 changelist（能夠理解就是 ci 數量）

 

最大的 client 有 6 百萬個文件（應該絕大部分是數據吧，要知道 chromium 項目也就不到 30 萬個文件）

 

文檔及相關數據文件也放上面

 

Reivew 工具叫 Mondrian（確認就是 Rietveld 的前身）

 

總體來講某 G 的代碼管理方式有不少可取之處，尤爲是代碼開放，能最大程度地調動開發人員的主動性與協做意識，從而創造出更大的價值。不過沒有版本管理這點是個雙刃劍，我也沒想好是否這樣會更好。

 

feature flag

 

由於沒有分支，代碼只有一份，因此要實驗新功能就得經過 flag 來控制的，這個 flag 由線上 Borg 系統來管理，能作到針對某一部分的 Cookie 開啓不一樣的 feature，方便進行對比抽樣。

 

若是某個功能最終不上線，後續須要手工刪除相關代碼。

 

這個 flag 開關功能在某 F 也有，我認爲這是大型網站是必備功能，但須要注意，這個系統自己會成爲關鍵節點，以前某 F 的相似系統掛過，直接致使整個網站大部分功能都關閉了，因此一旦出問題後果很嚴重。

 

嚴格的代碼檢查

 

聽說某 G 工程師大部分時間在寫單元測試，單元測試能夠保證 UI 無關代碼的質量，但對於頁面測試就很難了，雖然可使用 selenium，但某 G 內部你們都不肯意寫，我我的認爲這個問題確實無解，頁面隨便一改就致使大量測試失效，我還沒見任何一家公司解決（某 F 說他們用的是 Watir，但主要用於保證登陸等基本功能可用），目前看來惟一可行的就是自動頁面截圖 diff，某 G 在 Consumer Surveys 這個產品中也在嘗試。

 

聽說某 G 的項目大多沒有嚴格的上線時間點，因此不能以項目緊急爲藉口來不寫單元測試，這點和天朝不太同樣，你們更傾向犧牲質量來追求速度。

 

另外國外公司通常對瀏覽器兼容性問題都不怎麼關注，由於現代瀏覽器中的兼容性問題比之前好得多，這點某 G 和某 F 公司同樣，只支持高版本的 IE。

 

由於只有主幹，因此提交代碼很謹慎，須要通過 3 個主要階段：

 

代碼風格檢查

 

應該主要參考這個文檔

 

很是嚴格，聽說還會檢查命名什麼的

 

有段子說 Python 做者 Guido van Rossum 寫的 Python 代碼沒法經過檢查，因此一直沒提交。。。我認爲這是假的，由於他老人家寫的 rietveld 仍是挺符合某 G 規範的

 

單元測試檢查

 

代碼 owner 的 Review

 

提交一旦出錯可能會致使影響其它人的工做（由於每一個人都依賴主幹啊），甚至遭到其它國家 office 工程師的指責，因此你們對於代碼提交都很是謹慎，再三確認，壓力不小。

 

在單元測試、代碼風格和 review 的執行上，某 G 作得很完全，這點值得學習，國內你們彷佛更喜歡開發效率而不是質量。

 

前端如何開發

 

除了 Gmail、Maps、Plus 這樣的特例，基本上都是由後端模板生成頁面，不多項目使用 JS 來寫界面，更少使用 MVC 框架，這點其實在不少公司都差很少，好比某 B 也是同樣的，除了地圖及廣告管家等產品，其它產品基本上都是經過模板生成的。

某 G 的頁面是一般是由 Java 或 C++ 語言所寫的模版引擎生成的，並且開源出來了，分別是 Closure,Templates 和 CTemplate，話說某 B 在幾年前也本身寫了個 C++ 的模板引擎，但目前基本被淘汰了。

對某 G 來講，「前端」工程師要寫 Java 和 JavaScript，而「後端」服務主要是 C++（某些地方開始使用 Go 了，好比這個）。

前面說到招人時都要會 Java，這帶來的結果是大多數團隊成員更瞭解 Java 而不是 JavaScript，因而在這種背景下很天然地誕生了 GWT 這個神奇的東西，它在內部不少地方使用，按照內部人士的說法，主要的考慮是：

 

能自動生成跨瀏覽器瀏覽器代碼

 

結構規範，經過編譯器就能提早發現不少問題

 

能使用強大的 IDE 來提升效率（重構、自動完成、方便跳轉到定義等）