造就優良的軟體開發團隊文化的要素有哪些？

原文 What Makes A Good Engineering Culture

Soft & Share 取得 The Effective Engineer 作者 Edmond Lau 授權翻譯。

我最喜歡問面試的工程師的其中一個問題–告訴我各一件在他們以前上班的公司中，他們喜歡和不喜歡的軟體開發團隊(譯注 : 原文為 engineering ，但是內文都是意指軟體開發和團隊管理)文化。我已經面試了超過500人– 其中許多來自頂尖高科技公司像 Facebook ，Google，Amazon，Palantir，和 Dropbox – 隨著時間的演進，這個面試問題給了我了一種感覺讓我知道優秀的工程師在尋找什麼樣的軟體開發團隊文化和避免什麼樣的軟體開發團隊文化。從這些面談回應給我的反思和我自己從Google、Ooyala、和 Quora 7年的工作經驗，我精選了十件軟體開發團隊可以做的事用來建立一個良好的軟體開發團隊文化。

1. 最佳化重複步驟(iteration)的速度

快速地重複步驟速度增加工作的動機和令人感到興奮。因為基礎建設和官僚政治阻礙了代碼部署和新的功能上線，這是工程師在面試時想起來最常見而且最令人感到挫折感的事情，而且也是他們想離開目前公司的理由之一。

以組織而言，快速地重複步驟速度用意是給工程師和設計師擁有彈性和自主性，不用獲得允許而可以去做日常的決策。當我還在 Google 時，任何使用者可以看到的搜索結果變更，即使是低流量的實驗，都需要 Marissa Mayer(譯注 : 後來去 Yahoo 當了 CEO ) 在每週的 UI 審查會議批准。不必多說，此舉是要保護 Google 這塊搜尋的品牌，但是這種方式確顯著地阻礙創新。最佳化重複步驟速度也意味著有一個定義明確的產品推出的流程，所以經過有意義的投資時間後，取消產品上線這件事並不會不可預期的發生。

以基礎建設而言，最佳化重複步驟速度用意在建立了持續部署以支持快速驗證，高測試覆蓋率，減少建置和站台毀損的風險，快速的單元測試激勵工程師去執行它們，快速並漸增式編譯和重載以縮短開發時間。特別值得一提，持續部署，可承諾馬上進入產品準備上線狀態。在 Quora 用持續部署之前，這技術的好處曾經對我而言很難去內化，持續部署得到的好處對於提升重複步驟速度比起避免站台掛掉的風險還更有價值，至少以小型的工程團隊是如此。人們對於功能增加了感到興奮和有誘因去修復 bug ，因為變更很快的從實際的流量看到。相較於一週或數週建構一次，或是有更多的批次修改，持續部署也更明顯而容易去推理並查明從有限的程式碼提交中找出錯誤的來源。

從團隊的角度來看，快速的重複步驟速度也代表具有一群強而有力的領導者去幫助協調和推動團隊的努力。關鍵專案利益相關者(stakeholders)在做一個需求決策，需要有效率地決定並且承諾他們的選擇。借用Bill Walsh 的一句話，他是帶領舊金山49人(譯注一個美式足球隊)贏得 3 次超級盃的教練，優秀的領導者需要 “承諾(commit)，引爆(explode)、回復(recover)”，這意味要承諾攻擊計劃，執行它，針對結果做出反應。(註1) 一個團隊因猶豫不決而削弱其能力只會導致個人的努力舉步維艱。

2. 毫不留情地推向自動化

Instagram 共同創辦人 Mike Krieger 在他的技術演講 “Scaling Instagram” 中，談到 “為最小的操作負擔做最佳化” 是他的13人開發團隊在產品擴展到數千萬用戶時學到了關鍵的一課。(註2) 當產品成長時，每位工程師的操作負擔也會增加，這可以用每多少使用者需要多少工程師的比率來衡量或是多少功能需要多少工程師。例如，Facebook 以宣揚它的延展指標(scaling metrics)而聞名，像是每一位工程師支援超過100個萬使用者。(註3)

自動化解決方案和將重複性任務腳本化(scripting)是很重要的，因為這件事釋放出了工程團隊的時間可以用在實際產品開發的工作上。如果服務器失效，確保它們盡可能會自動重新啟動，並且會在流量高峰時，簡單而且快速地複製自己，這是在規模擴大時，唯一明智的方式去管理複雜度。以短期眼光，總是會有誘惑寧可採用快速匆忙拼湊的手動折衷方法，而不要用自動化和測試一個長期的修正。

Etsy 的座右銘–“度量任何事，度量一切” (註4) 這樣的需求可以使用開放原始碼的監控與圖表工具像是 graphite 和 statsd 來達成，這句話強調了自動化的一個重要面向–自動化必須被數據和監控所驅動。如果沒有監控和日誌去了解發生什麼事、有些事情是如何出錯、或是為什麼出錯了，自動化變成是困難的一件事。一個好的遵循座右銘會是– “度量任何事，度量一切，儘可能自動化一切”。

3. 建立正確的軟體抽象層

我的 MIT 教授和大學研究指導教師 Daniel Jackson 指出了良好的軟體抽象層重要性 (註 5)

“選擇對的抽象層設計，程式設計將會從抽象層設計去自然地遵循，模組將會有小而簡單的介面 ; 不需要過度的重新組織代碼，加入新的功能也很容易適應。然而選擇錯誤的抽象層設計，程式設計將會出現一連串令人討厭的意外 : 介面將會變成結構複雜而且笨拙的，程式設計師被迫去適應無法預期的交互作用，甚至連最簡單的變更都很難去進行。”

可以讓數千名Google 工程師可以建置可延展性的系統其中一部分原因是 Google 擁有像是 Jeff Dean 和 Sanjay Ghemawat 這樣真正聰明的工程師建構了像是 MapReduce， SSTable, Protocol Buffers 簡單且多才多藝的抽象層，相同的，可以讓 Facebook 工程師去延展他們的系統其中一部分原因是他們專注在相似的核心抽象層像是 Thrift，Scribe，和 Hive。在 Quora 有一部分原因可以讓設計師更有效率地建構產品是因為有建置在其上相當簡單而且容易了解的 Webnode 和 Livenode 。

保持核心抽象簡單而且通用減少了客製化解決方案的需要並且增加了團隊的熟悉度與具備有共同抽象層的專門技術。逐漸普及和可靠的系統像是 Memcached， Redis， MongoDB，等等已經減少需要自行建立客製化儲存和快取系統。寧可讓開發團隊像漏斗狀，灌注注意力在少數的核心抽象層也不要分散注意力在特定的解決方案。這也意味共用的程式庫會更穩健，監控變得更聰明，性能特徵得到更好的理解，測試取得更多的全面性。所有這一切都有助於一個可以降低營運負擔的簡單系統。

4. 使用程式碼審查流程專注產出高品質代碼

維護一個高品質的程式碼庫，提高了整個工程團隊的生產力。整潔的程式碼更容易理解，更快速去開發，更適應於變化，並且較不容易受 bug 交互影響。一個健康的程式碼審查流程讓這一切成真。

建立及時的程式碼審查流程，無論是在 pre-commit 或是 post-commit 後，在幾個方面提高了程式碼品質。首先，有人要審查你的程式碼的同儕壓力和因為提交了設計不良的程式碼將會浪費同事的時間，這對於採用不當技巧的、無法維護的、未經測試的程式碼有嚇阻的作用。其次，程式碼審查提供了程式碼審查者和作者交流的機會，彼此互相學習而寫出更好的程式碼。

如果程式碼審查流程很容易被工程團隊的其他成員容易接近使用，那麼程式碼審查也順便帶來以下的好處 a) 增加對及時審查程式碼方式的責任感 b) 讓團隊成員–特別是新進的成員，從其他人好的程式碼審從中學習 c) 加快宣傳最佳的程式設計實踐。

反觀，追求快速的開發團隊沒有把時間花費在程式碼審查，而忽略了不好的程式碼很容易累積技術債。Ooyala 在它非常早期公司剛開始的時候，習慣於最佳化盡可能地實作出越多的功能越好，卻疏於做程式碼審查，最後造成了結果–雖然最初的產品可以很快地推向市場，但是產生的程式碼變得修改起來很痛苦，我們花了一年的時間也只是在改寫脆弱的程式碼以消除技術債。

Google 在公司還很小的時候，對於所有的程式碼有做 pre-commit程式碼審查但規模較小的團隊並不需要那麼全面或嚴格，而且所有程式碼不需要同樣嚴格地審查。Ooyala，我在那裡的時候採用了 post-commit 方式通過電子郵件通知來審查核心或是高風險的程式碼變更。在 Quora，我們透過 Phabricator進行的所有程式碼審查，大部分透過 post-commit 方式，模型( model )或控制器( controller )程式碼和視圖( view )程式碼採用了不同的標準; 敏感程式碼或從新進工程師產出的程式碼，我們使用 pre-commit 做程式碼審查或是試著在提交程式碼前花幾個小時內做審查。

5. 維持一個彼此尊重的工作環境

同事之間的尊重形成了任何形式開放溝通的基礎。一個讓人們感到自在去互相挑戰對方想法的地方，也是一個合理的概念會經由辯論而前進的地方。一個人們很容易被冒犯的地方，也是重要的回饋會被壓抑的地方。

在 1948，Alex Osborn 介紹了知名的腦力激盪方法，這在過去的幾十年工作環境中一直很受歡迎，參加者會聚在一起，拋開批評和負面回饋並且共同一起激盪出創造性的想法，不會有被批判的恐懼。(註 6) 這種形式的腦力激盪會議關鍵在它尊重任何潛在創意。最近的心理學研究已經開始推翻 Osborn 的做法，建議在腦力激盪會議鼓勵辯論在實際上有助於避免群體思維，並產生更有效的思路。在這項研究中點指出，抨擊是針對概念想法而不是做人身攻擊，這在一個彼此尊重的環境中變得更加關鍵。(注 7)

工程往往跨越廣泛的領域(系統，機器學習，產品等)而且不是每個人在每一個領域都同有同樣的專業知識。一個強大的團隊裡面應該有一些人對特定領域專精，即使他們跟別人相較之下有不足之處。這樣有時候說起來有點複雜，例如讓系統工程師來評估產品工程師的專長，但去尊重這些差異性在一個健康的工程師文化是很重要的，而且並不能完全根據自己的優勢去評斷。

6. 建立程式碼共享所有權

當很自然地每個人對於程式碼庫不同部分的程式碼或是架構變得逐漸精通，就沒有人會覺得他們是任何程式碼一部份的擁有者或是唯一的維護者。以短期而言，當一個人擁有特定範圍的程式碼一年會成為專家或是更能增加工作效能，但是這種做法最終從長遠看對團隊而言是傷害的。

在組織中，共享程式碼所有權提供了三個好處。首先，讓巴士因子(bus factor 見註 8)大於一使維護者釋放壓力並且幫團隊降低了風險如果維護者離職了。對於一個人在放假中還不用擔心工作是很困難的一件事。我肯定不會想念我在 Ooyala 是唯一維護日誌處理器開發者的那段日子，當我在夏威夷度假爬火山時，竟然還會收到簡訊要求處理問題。

第二，共享程式碼所有權授權給那些沒有深入特定區域程式碼的工程師貢獻新鮮的見解。讓工程師免於屈就於特定專案的感覺並且鼓勵他們參與不一樣的專案，這有助於維持工作的樂趣，並提升員工學習意願和動機。從長遠來看，它降低組織有些工程師感到成長停滯而定離開的風險。

第三，共享程式碼所有權，必要時要更迅速地完成戰略目標，讓多個團隊成員共同協作(swarma together: 來自敏捷開發的技術)一起解決高優先順序的問題殿定了基礎。孤立程式碼的所有權(譯注穀倉效應)，責任通常落在一個或兩個人身上。

一個錯誤發生在許多工程組織單位–當團隊還在很小的時候，太早切割成許多子團隊並有各自的技術領導者。子團隊打造的所有權這道牆，並減少了動機去越過那道牆。因為個人可能只會以子團隊的目標來評估。當我還在 Ooyala 公司時還有子團隊，我錯過了與其他團隊其中一些人一起工作的機會。他們已經採用了敏捷開發流程並且有更大的重點放在共享的程式碼所有權，我聽說已在工作幸福感和生產力上有巨大的進步。在 Quora 工作的初期，讓我樂在其中的一個原因是我們超越團隊來強調專案，所以我有機會參與專案從使用者增長、機械學習、調節工具、推薦機制、分析、網站速度和垃圾訊息檢測。

7. 投資於自動化測試

單元測試的覆蓋率和一定程度的整合測試覆蓋率是唯一可以延展的方法來管理由大型開發團隊維護的較大的程式碼基底(codebase)，不會經常破壞了建置(build)或是產品。自動化測試提供了信心和針對了要提高程式碼品質而做大規模的重構有意義的保護。缺少了嚴格的自動化測試，需要由工程團隊或外包測試團隊做手動測試的時間是容易變成令人望而卻步，而且很容易陷入一種恐懼去改善一段程式碼的文化，只是因為它有可能被破壞了什麼。

在實務中，當團隊成長時，自動化測試是讓持續部署可以作業的需求。當產品成長時程式碼基底(codebase)的大小也隨著時間成長，但是當新進工程師加入，團隊成員對於程式碼基底(codebase)的平均熟悉度也隨之下降。當程式碼在開發者的腦海裡還記憶猶新的時候，這時候測試和驗證程式碼比較容易被原開發者來完成，相較於寫完程式碼一個月後或是一年後再來修改。鼓勵強大的單元測試的文化，將驗證責任轉移朝向原開發者。

8. 分配 20 ％的時間策略

Gmail 發現它的根源是在 Paul Buchheit 的 20% 專案，而且他只花了一天的時間做出了第一版。(註10) Google 新聞、Google Transit 和 Google Suggest 也是從 20 % 專案發起的。在 Google ，我用 20％的時間，寫了一個 Python 框架，使得它來建置搜索頁面演示顯著更容易。雖然 Google 現在的 20% 時間跟公司剛開始的那段日子相較，產出是比較少的。(註11) 讓工程師花 20 ％的時間做某件事情跟他們的負責產品路線(product map)無關的概念，依然是小型工程組織創新的搖籃。

我還在 Ooyala 工作時，沒有正式有20％的時間策略。但我花了一些時間寫了一個 Flex 和 ActionScript 命令列(command-line)編譯工具，加速了團隊的構建(build)時間。我完成這個工具的時候剛好 Adobe 的 Flex Builder 工具鍊開始走下坡，該工具仍然在使用，即使當工程團隊的規模較原本成長了三倍。經過一年實驗，Atlassian 也採用了20％的時間策略。(註12) 一種受到 Facebook 的喜愛的 20% 時間策略變種，Ooyala 後來也採用了，就是定期的舉辦黑客松(hackathons)–一個通宵達旦的活動，其中的規則是除了你平常的專案，你可以做任何事。(註13)

自上而下的方法做產品規劃，而且必須聚焦公司的總體方向，無法自最接近基層的工程師取得最多的創意。只要工程師為他們 20％的時間負責，並且專注於可產生高影響力的變更，這些專案可以跨出較大的腳步並往進步方向前進。沒有正式的 20％的時間，這些事仍然是可能發生，但是對於工程師和設計師去嘗試瘋狂的概念是比較困難的。專注的人基本上必須利用週末的時間或是自己的假期來做這些嘗試。

9. 建立一個持續學習和改善的文化

學習和充分的得到挑戰是進入心理學教授 Mihaly Csikszentmihalyi 稱之為“心流”狀態(或是神馳狀態)的需求，如果人進入這樣的狀態完全集中精神和被他們正在做的事所驅動，他們甚至忘了去追蹤時間。(註14) 通過快速的重複步驟(iteration)週期得到直接和快速的回饋迴圈(feedback loop)是進入“心流”狀態的另一種需求。

每週的技術講座提供了論壇(forum)讓工程師們分享他們的設計或是開發的作品，創造一個機會，讓工程師以他們的工作感到驕傲和讓團隊學習到更多他們目前工作以外的技術。將內部流程文件化，像是 email 服務是如何運作的或是如何對搜尋服務做排名變化，這也給予工程師權力自己主動去學習和探索新的技術，恰到好處跟 20 % 時間策略形成互補。在 Quora，我們在內部有自己的 Quora 服務器，在上面我們會問跟產品和開發相關的問題。

一個建立學習文化的必然結果是專注在師徒(mentoring)制和教育訓練去確認每一個人有基本的演算法、系統和為了確保產品成功所具備的開發技能。隨著工程組織成長更大要花更多功夫投入在招募上(特別是學院招募)，也需要花更多力氣投注在師徒制輔導和教育訓練。對於一位獨立的導師(mentor)，每天花一個小時在一位剛到職4周內的新進工程師的工作上，這似乎是一件沈重的工作，但是這個投入時間少於新進工程師一年內將會花費所有時間的 1% ，這有了很明顯的槓桿作用在決定新進工程師是否成功融入團隊。

10. 招聘最好的人

招聘最好的人，是上述我所提出的許多點論述的基礎。要去尊敬一位你認為對方是B級工程師的專業能力是很困難的一件事。如果你不信任某人的產品直覺(product instincts) ，讓他們在產品開發上有自主權是很困難的。如果沒有足夠的軟體工程經驗，要去識別正確的抽象層來建立是很困難的。如果沒有其他聰明的工程師去挑戰你的概念和驅使你朝向簡單化，很容易掉入建構一個複雜軟體架構的陷阱。

在矽谷流傳一個 Steve Jobs 創造的說法 “A 級玩家聘請 A 級玩家。B 級玩家聘請 C 級玩家”。(註15 16) 專注在招募並且聘雇對的人是困難的但是對於一個工程組織有效率地成長是很關鍵的。Yishan Wong ，他先前在 Facebook 擔任工程經理和主管，主張招聘已成為大家在工程組織的首要任務，並不僅僅針對管理者，還包含工程師。(註17) 他還準確地指出 “招聘最好的” 和 “招聘最好的候選者” 之間的區別。

Ooyala 的早期，我們因為客戶排入的工作而如此不堪重負，我們幾乎降低招聘的標準所以我們可以聘雇足夠的工程師來完成所有的工作。我很高興我們沒有這樣做，從較差品質程式碼和團隊中的較弱工程師產生的技術債將不會停止傷害團隊和產品。

建立一個良好的軟體工程文化肯定要花費很多的功夫，但由此產生的工作環境是非常值得的。

這篇部落格文章源自於 Edmond 在 Quora 上的回答。

如果要找 Edmond 演講關於軟體工程文化相關主題的演講可以跟他聯絡。