Google 教我有關擴展軟體開發團隊的幾個要訣

Esa

7 年前

本文由 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 一則回覆