【為什麼我們挑選這篇文章】想到 Google，你第一個聯想到的是他的搜尋、翻譯、地圖、商店，還是 Gmail，啊別忘了 YouTube 也是，要一次操控這麼多大產品，還要管理內部的營運，究竟要有多精準或嚴格的管控，才能維持這間大企業的營運？
這裡將從一位前 Google 工程師的角度，來看 Google 內部的工程文化如何在培養、管理人才上同時兼顧，還有為何能在員工超過 50000 名的現下，達到高水平的成功。
本篇作者為 Edmond，目前教導軟體工程師和技術經理如何有效率的建立有意義的影響力。他為 Quip 早期的軟體工程師，曾在 Quora、Google和 Ooyala 帶領軟體開發團隊。著作：The Effective Engineer 。（責任編輯：張瑋倫）
本文由 The Effective Engineer 作者 Edmond Lau 授權翻譯
每週，一群 Google 員工會在世界各地辦公室的洗手間門板上貼上一頁紙分享這一週的測試技巧。某一週，可能討論 dependency injection，並提供在各種語言如何使用它的簡單範例；另一週，可能分享如何設定一個工具來測量團隊程式碼基底（codebase）的測試覆蓋率。
「測試在洗手間」（註1）的首創精神是一個古怪和有趣的方式來教工程師新的和有用的知識，如同他們正在進行自己的業務。 如此也強化了 Google 工程文化的一個關鍵優勢：有效地向大型工程組織的成員傳播一套一致的、有見地的最佳實踐。
我在大學一畢業就加入了 Google 搜尋品質小組，從2006年年中至2008年年中，公司從大約8000名員工增長到近20000名。（註2）（註 3）我在我的第一個專案中與兩位非常有才華的工程師合作，在短短的六個月內，我們在 google.com 上進行原型、測試和推出了一個新功能，每天向數百萬用戶展示相關的搜尋。
身為團隊中象徵的 Noogler（google 新進工程師），在整個體驗中令人印象深刻的是，公司如何能夠讓像我這樣的新進工程師很快融入團隊並高效地工作。類似 StarTrek 的 Borg 種族，（註 4）公司已很精通同化新工程師的藝術。
如果沒有 Google 工程文化的某些關鍵元素，像這樣規模的團隊要在短時間內發揮影響力發佈新功能是非常困難的。 這些元素使我能夠在短時間內很快地了解 Google 的程式碼基底（codebase）、工具和基礎架構。
也是同樣的元素，使公司達到目前的規模，擁有超過50,000名員工。一些前 Google 員工可能會抱怨怎麼公司已經變得這麼緩慢或是官僚，（註 5）但不可否認的是，它仍然能夠在如此大的規模下達到高水平的成功，也是 Fortune 100強最值得工作的公司。
以下是我從 Google 工程文化中學到的六個核心原則，你可以從以下各項中學習：
- 致力共享工具和抽象（abstractions）的工程資源
從很早以前起，Google 對於整個工程組織共用的工具和抽象（abstractions），如 Protocol Buffers、MapReduce、BigTable 等方面密集地投資。 這種好好地一次把問題解決然後讓所有內部的人都能採用的態度最終獲得很高的回報。
每個團隊不用花太大的心力去考慮要使用哪些工具，有專門的工具團隊服務且專注於改善，提高工程團隊的生產力，這些改善很容易傳播給每位已在使用工具或服務的人。
和既有的工程組織（每個團隊可能使用非常不同的工具鏈）形成對比，這一理念也意味著，一旦你已經知道基礎的建構區塊後，便能很容易地理解許多專案背後的設計。這種方法的缺點是，有時你可能會被迫把你的使用案例做些調適，以配合某些特殊支援的工具，甚至它對於你目前的工作來說不是最好的。
- 為新進工程師投資可重複使用的培訓教材
我能夠迅速在 Google 中有生產力的原因之一是因為 Google 一直以來投入大量資源投入到名為 codelabs 的培訓文件中。
Codelabs 包含了公司的核心抽象層（core abstractions），解釋了為什麼它們被如此設計，突顯程式庫中的相關片段，然後通過幾個實踐的練習驗證理解。沒有這些，我需要更多的時間來了解我能有效率工作所需要知道的眾多技術，這也意味著我的同事不得不花更多的時間向我解釋這些知識。
我在 Google Codelabs 的正面經驗強烈地啟發我後來在 Quora 的到職流程推動 codelabs 的決心。
- 標準化程式設計風格
關於空格、大寫、行長、是否使用智慧指標（smart pointers）等的每個約定可能單獨看起來微不足道，但是當你達到 Google 的規模時，具有巨大的影響。我不會是第一個承認，當程式碼審查者對我的程式碼挑三揀四，只因為我不正確地縮進一行或因添加兩個字符而超過規定的行列長度很煩的人。
但是因為每個人都遵循相同的規定，瀏覽原始碼明顯地容易許多。在交換團隊或處理跨功能專案時，將需要費點功夫來學習新團隊的規定。當你的團隊小的時候，很容易就忽略的像規定這種事，但隨著程式碼基底（codebase）和團隊成長到某個程度，需要花在變更上的力氣越來越多，你會開始意識到需要一些一致性。
如果可能，儘早規劃團隊一致的規定，或者也可直接使用 Google 開源的樣式指南（style guides）。
- 透過程式碼審查提高程式碼品質
要求程式碼審查並為每個更改以程式來強制執行，減慢了迭代速度，但優化了程式碼的品質。新進工程師將由於收到他們需要的回饋，可快速掌握最佳實踐並收斂程式碼的品質到可接受的水準。
整體上有更高品質的程式碼意味著新進工程師以這品質起始建模，如此將更有可能一開始就寫出更乾淨的程式碼。 因此，程式碼審查是有助於公司擴大規模還能讓所開發的軟體維持高品質的流程。
- 取得正確的數據（而且要很多）來解決許多問題
Google 研究部主任 Peter Norvig 經常談到「數據由不合理變有效」（註6）（註7）（譯註 : 經由合理化模型將許多混亂的文字、圖像和影片變成有效訊息），以解決複雜的問題。
正確的數據可以幫助你了解使用者、分析辦公室政治、解決爭議，並追踪進度。開發日誌和數據基礎架構（例如 Sawzall 和 MapReduce）使 Google 的工程師可以篩選大量數據。
- 自動化測試以擴展你的程式碼
Google 有非常強大的單元測試文化，「測試在洗手間」是其中一個明顯的案例。幾乎每一個我所做的程式碼修改都伴隨著一個單元測試，程式碼審查人員將嚴格檢查它們。
這使得開發一個指定的變更比較慢，但也意味著成百上千的工程師可以在程式碼基底（codebase）裡相同的部分做擴充與修改，而不犧牲太多的品質或可靠性。 類似投資共享工具的作法，Google 也共享測試框架並致力最佳測試實踐的教育訓練，讓寫測試更加容易。
後來我到 Ooyala 和 Quora 幫助建立產品和團隊時，在 Google 有效的實踐方法（以及無效的）強烈地告訴我要針對我所待的地方想想做什麼能創造良好的工程文化。
在 Google 規模的環境運作良好的決策並不一定會在不同成長階段的組織有效。 每一工程方面的決策都牽涉到一整組的取捨，不過 Google 的工程文化提供一套很不錯的取捨參考標準幫助你開始。
（此文源自作者在 Quora 一則回覆）
- “Testing on the Toilet”, Google testing blog
- “2006 Financial Tables”
- “2008 Financial Tables”
- “Borg (Star Trek)”, Wikipedia
- Dhanji R. Prasanna, “Waving Goodbye”
- Peter Norvig, “The Unreasonable Effectiveness of Data”, YouTube
- Alon Halevy, Peter Norvig, and Fernando Pereira, “The Unreasonable Effectiveness of Data”, IEEE Intelligent Systems
原文: What Google Tought Me About Scaling Engineering Teams
（本文經原作者 Soft & Share 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為〈Google 教我有關擴展軟體開發團隊的幾個要訣〉。）
延伸閱讀
從 Google 工程師到創業 CTO，這 8 個理念讓他一路堅持下來
Google 工程師親授：菜鳥開發者一定要投資的十大標的
4 年破億！前 Google 工程師證明「中國製造」也能在歐美創造品牌神話
◎ TechOrange 正在招募「TechOrange 社群活動部專員/經理」唷！ 如果你喜愛觀察網路社群行為，擅網路語彙溝通，文字感佳 而且希望參與活動企劃與執行工作 歡迎你提供履歷自傳寄至 jobs@fusionmedium.com 來信主旨請寫明：【應徵】TechOrange 社群活動部專員/經理：您的大名