【導讀】一位在谷歌從事工程師的朋友為大家帶來了谷歌工程師文化中的幾個核心原則，國內工程師都來瞧瞧別人是如何練就過硬的本領的。同時也看看國內外的差距到底有多大？
我大學畢業后便加入Google的搜索質量團隊，在2006年中旬到2008年中旬在其工作，在這期間，公司的規模從8000人上漲到20000人。在我的第一個項目，我同兩位極具天賦的工程師一起工作，短短六個月，我們原型化、測試并啟動了網站的新功能，每天向數百萬用戶在google.com上展示相關搜索。作為團隊的新員工，自始至終最突出的感受是在這樣的環境中，公司如何能使像我這樣的新工程師快速成長起來。
如果這不是Google工程文化的關鍵要素，對于我們這樣規模的團隊在如此短時間內發布新特性是極為困難的。這些要素能夠讓我迅速地獲得Google的代碼庫、工具和基礎設施。它們也是使公司能夠達到今天50000雇員規模的原因。
一些前谷歌員工可能抱怨公司變得遲緩和官僚，但是不可否認它已經獲得很高的成就和很大的規模，在《財富》評選的100家最適合工作的公司中名列前茅。
這有我從谷歌工程文化中獲得的六個核心原則，你可能能夠從中獲益：
把工程資源用于共享工具和抽象概念。在早期谷歌在工具和抽象概念上大力投資，例如Protocol Buffers，MapReduce，BigTable和其他在工程中自始至終都會用到的東西。解決問題好的態度并使得每個人能夠接受已經帶來巨大的收益。每個團隊都花費較少的心理周期選擇使用哪個工具，專注于工具的團隊能夠更關注提升工程生產力，和改善已經使用的工具和服務。每個團隊可能使用截然不同的工具鏈，這也意味著當你學習了基本單元結構后，更容易理解許多項目背后的設計。這個方法的負面影響就是有些時候你可能感覺你的case是被強行塞入一個特別的良好支持的工具，即使它不是最好的。
在新工程師培訓中投資可重復使用的訓練材料。我在谷歌能夠迅速變得如此高產的一個原因是公司在培訓材料上面花了大力去投資，其稱之為Codelabs，Codelabs包括了公司的核心抽象模型，解釋它們為什么被設計出來，突出代碼庫的相關片段，以及通過實現練習驗證理解它們。如果沒有它，我將會花更多的時間來學習各種我需要去了解的各種技術，這也意味著我的隊員要花費更多的精力向我去解釋它們。我在谷歌這樣積極的經歷，強有力的影響了我在后來的Quora新人培訓過程中大力推崇Codelabs使用的決定。
標準化編碼約定。每個關于空格、大小寫、行長度、是否使用智能指針等約定，可能似乎是不重要的，但是到了谷歌這樣的大規模時會帶來巨大的影響。我不是第一次承認，當代碼校驗人員挑刺我的代碼令我感到十分不愉快，就因為我沒有正確的縮進或在行長度超出了規定的兩個字符。但是因為大家都遵循同樣的約定，使得瀏覽代碼變得大大容易。當更換團隊或在跨部門項目中工作時，這幾乎沒有額外支出去學習新團隊的約定。當團隊規模很小時，約定是那種很容易被忽視的東西，但是在代碼和團隊規模逐漸壯大在這方面越來越做出改變，這樣你事實上希望從始至終都是一致。如果可能早期在約定一致性上保持一致，或者使用谷歌開源的風格指南。
通過代碼復審（Code Review）提升代碼質量。對每次改變進行代碼復審減緩了迭代更新的速度，但是提升了代碼質量，新工程師收到反饋后，他們需要迅速的采取最佳的實踐并專注于公認的代碼質量等級。總體的代碼質量越高，也就意味著新工程師在模仿周圍人員的代碼同時，初期就會寫出更加簡潔的代碼。因此，代碼復審有助于公司在較大規模上位置較高的軟件質量。
用正確數據解決很多問題。谷歌研發主管Peter Norvig經常談到在解決復雜問題上“不合理的數據有效性”。正確的數據能夠幫助你了解用戶，劃分辦公室政治，解決爭論，并讓你跟上進度。開發日志和數據基礎工具，如Sawzall和MapReduce，使谷歌的工程師從大量數據中篩選出來變為可能。
自動化測試來衡量你的代碼。谷歌有十分強烈的單元測試文化，“廁所測試”就是一個例子，差不多我每做一次代碼的改動都伴隨一個單元測試，代碼復審員將會嚴格地檢查他們。這讓開發變慢，但它也意味著成百上千的工程師可以改變代碼庫中的同一部分而不會犧牲過多的質量和可靠性。谷歌以同樣的方式在共享工具上進行投入，它也會共享測試框架，并通過最好的測試實踐讓大家寫測試變得更容易。
當我后來在Ooyala和Quora幫助他們構建團隊和產品時，谷歌的工作強烈地讓我思考，在哪些地方什么會形成良好的工程文化。然而，在谷歌這樣規模的公司工作好并不一定意味著會在不同機構的不同發展時期的工作同樣會好。每個工程決策都包括一系列權衡，但是谷歌工程文化提供了一部分權衡，而你可以從這里開始。
