我大學畢業(yè)后便加入Google的搜索質(zhì)量團隊，在2006年中旬到2008年中旬在其工作，在這期間，公司的規(guī)模從8000人上漲到20000人。在我的第一個項目，我同兩位極具天賦的工程師一起工作，短短六個月，我們原型化、測試并啟動了網(wǎng)站的新功能，每天向數(shù)百萬用戶在google.com上展示相關搜索。作為團隊的新員工，自始至終最突出的感受是在這樣的環(huán)境中，公司如何能使像我這樣的新工程師快速成長起來。

　　

如果這不是Google工程文化的關鍵要素，對于我們這樣規(guī)模的團隊在如此短時間內(nèi)發(fā)布新特性是極為困難的。這些要素能夠讓我迅速地獲得Google的代碼庫、工具和基礎設施。它們也是使公司能夠達到今天50000雇員規(guī)模的原因。

　　

一些前谷歌員工可能抱怨公司變得遲緩和官僚，但是不可否認它已經(jīng)獲得很高的成就和很大的規(guī)模，在《財富》評選的100家最適合工作的公司中名列前茅。

　　

這有我從谷歌工程文化中獲得的六個核心原則，你可能能夠從中獲益：

把工程資源用于共享工具和抽象概念。在早期谷歌在工具和抽象概念上大力投資，例如Protocol Buffers，MapReduce，BigTable和其他在工程中自始至終都會用到的東西。解決問題好的態(tài)度并使得每個人能夠接受已經(jīng)帶來巨大的收益。每個團隊都花費較少的心理周期選擇使用哪個工具，專注于工具的團隊能夠更關注提升工程生產(chǎn)力，和改善已經(jīng)使用的工具和服務。每個團隊可能使用截然不同的工具鏈，這也意味著當你學習了基本單元結構后，更容易理解許多項目背后的設計。這個方法的負面影響就是有些時候你可能感覺你的case是被強行塞入一個特別的良好支持的工具，即使它不是最好的。

　　

在新工程師培訓中投資可重復使用的訓練材料。我在谷歌能夠迅速變得如此高產(chǎn)的一個原因是公司在培訓材料上面花了大力去投資，其稱之為Codelabs，Codelabs包括了公司的核心抽象模型，解釋它們?yōu)槭裁幢辉O計出來，突出代碼庫的相關片段，以及通過實現(xiàn)練習驗證理解它們。如果沒有它，我將會花更多的時間來學習各種我需要去了解的各種技術，這也意味著我的隊員要花費更多的精力向我去解釋它們。我在谷歌這樣積極的經(jīng)歷，強有力的影響了我在后來的Quora新人培訓過程中大力推崇Codelabs使用的決定。

　　

標準化編碼約定。每個關于空格、大小寫、行長度、是否使用智能指針等約定，可能似乎是不重要的，但是到了谷歌這樣的大規(guī)模時會帶來巨大的影響。我不是第一次承認，當代碼校驗人員挑刺我的代碼令我感到十分不愉快，就因為我沒有正確的縮進或在行長度超出了規(guī)定的兩個字符。但是因為大家都遵循同樣的約定，使得瀏覽代碼變得大大容易。當更換團隊或在跨部門項目中工作時，這幾乎沒有額外支出去學習新團隊的約定。當團隊規(guī)模很小時，約定是那種很容易被忽視的東西，但是在代碼和團隊規(guī)模逐漸壯大在這方面越來越做出改變，這樣你事實上希望從始至終都是一致。如果可能早期在約定一致性上保持一致，或者使用谷歌開源的風格指南。

　　

通過代碼復審（Code Review）提升代碼質(zhì)量。對每次改變進行代碼復審減緩了迭代更新的速度，但是提升了代碼質(zhì)量，新工程師收到反饋后，他們需要迅速的采取最佳的實踐并專注于公認的代碼質(zhì)量等級?？傮w的代碼質(zhì)量越高，也就意味著新工程師在模仿周圍人員的代碼同時，初期就會寫出更加簡潔的代碼。因此，代碼復審有助于公司在較大規(guī)模上位置較高的軟件質(zhì)量。

　　

用正確數(shù)據(jù)解決很多問題。谷歌研發(fā)主管Peter Norvig經(jīng)常談到在解決復雜問題上“不合理的數(shù)據(jù)有效性”。正確的數(shù)據(jù)能夠幫助你了解用戶，劃分辦公室政治，解決爭論，并讓你跟上進度。開發(fā)日志和數(shù)據(jù)基礎工具，如Sawzall和MapReduce，使谷歌的工程師從大量數(shù)據(jù)中篩選出來變?yōu)榭赡堋?/div>