leiphone 董飛

編者按：本文作者Edmond Lau，公號「董老師在矽谷」翻譯首發。

我作為面試官最喜歡問工程師的問題是：在他們以前的公司，他們喜歡和不喜歡的關於工程師文化的事是什麼？我採訪了500多人——其中許多來自頂尖高科技公司，如Facebook，谷歌，亞馬遜，Palantir，和Dropbox，隨著時間的推移，這種面試問題也告訴我：優秀工程師喜歡的和盡量避免的地方。根據採訪答復和我個人經驗，從過去七年跨越谷歌，Ooyala和Quora的工作，我總結出為建立一個良好的工程文化，一個團隊可以做的十件事情。

1、優化迭代速度

快速迭代有助於提高工作積極性和興奮度。一些工程師在面試時說到他們離開公司的原因，其中最常見的也最令人沮喪的是基礎設施和繁冗流程阻礙他們部署代碼或者上線功能。

在組織上，快速迭代讓工程師和設計師更靈活自主地作日常決策。我在谷歌，任何用戶可見的搜索結果改變，即使是低流量的實驗，也需要瑪麗莎·梅耶在每周UI審查批准。雖然這允許谷歌保護它的搜索品牌，但它明顯阻礙了創新。優化迭代速度也意味著，按照明確定義的流程推出產品，避免投入大量時間後意外發生。

優化迭代速度意味著建立持續部署以快速驗證，提高測試覆蓋率，減少構建和網站宕機次數，快速單元測試，並鼓勵大家來運行，快速增量編譯和重新加載，以縮短開發時間。持續部署，提交到線上特別重要。比如在Quora它提供的迭代速度至少在小工程隊利大於弊（線上出錯的風險）。人們更興奮地看到功能和修復Bug是因為很快看到了實時流量的變化。這要比超過一周或成批的代碼提交，要更容易推斷和精確定位錯誤源的位置。

團隊智慧，快速迭代的速度意味著有強有力的領導者，幫助協調和推動團隊的工作。在決定關鍵點上負責人需要有效地作出決定，並承諾他們的選擇。借用比爾·沃爾什（領導49人隊3次進超級碗）的一句話：強有力的領導者需要「承諾，引爆，恢復」，這意味著承諾攻擊計劃，執行它，然後看反應結果。優柔寡斷的團隊只會導致個人努力白費。

2、盡量自動化

在技術講座「規模化Instagram」上，Instagram的聯合創始人邁克·克里格引「優化最少的操作負擔」作為一個重要的教訓，領導他的13人團隊將用戶增長到幾千萬。產品的增長意味每個工程師的操作負擔加重，如用戶跟工程師或者特定功能跟工程師的比率。像Facebook號稱每個工程師支持超過100萬的用戶比例指標。

自動化解決方案和讓腳本去重復執行任務很重要，因為它們解放工程團隊，讓他們為實際產品工作。確保在流量高峰期，如果有服務失敗並自動重啓的情況下，能找到替代者是管理大而複雜產品的明智方案。在短期內可以對應用做快速修復，而長期還是要依賴自動化測試，這需要權衡。

Etsy的座右銘是「衡量所有，衡量一切」。支持像開源監控和製圖工具graphite和statsd突出自動化 -——即自動化必須由數據和監控驅動。如果沒有監控和日誌你怎麼知道什麼事情錯了，為什麼錯。自動化是困難的。一個後續的座右銘是「衡量所有，衡量一切，並盡可能自動化。」

3、建立合理的軟體抽象

我的麻省理工學院教授和本科生研究顧問丹尼爾·傑克遜說的軟體抽象的重要性：

"選擇正確的方式，程序化自然而然地設計;模塊化就是有小而簡單的界面; 新功能在不影響全局的情況下產生。要是搞錯的話，程序將是一系列的討厭的坑：接口很笨拙因為他們無法適應一些意料之外的交互，即使是最簡單的改動也將很難維護。"

在谷歌，什麼讓數千名工程師建立可擴展的系統——因為他們有非常聰明的工程師像傑夫·迪恩和桑傑·格瑪沃特，創建了簡單但豐富的抽象，如MapReduce，SSTable，Protocol Buffer等。什麼讓Facebook工程這麼支持大規模——是因為專注於核心，同樣喜歡抽象和簡單，Thrift, Scribe, Hive。是什麼讓設計人員能夠在Quora有效構建產品，Webnode，Livenode也是基於同樣的理解。

保持核心抽象的簡單和減少自定義解決方案並增加團隊熟悉度和對專業知識的抽象。日益普及的系統像Memcached，Redis，MongoDB等都是降低建立客製化儲存和緩存系統的必要性。團隊重點轉移到少數核心抽象，而不是分裂在很多臨時解決方案，讓公共庫更穩健，監控更智能，性能更易理解，測試更全面。所有這一切都有助於搭建一個簡單的系統，降低操作負擔。

4、注重代碼審查，編寫高代碼品質

維持高品質的代碼庫增加了整個工程團隊的工作效率。整齊的代碼更容易便捷發展和維護，更適應變化，不容易引入錯誤。健康的代碼審查過程使之成為可能。

建立及時代碼審查流程，不管是預提交或提交後，代碼審查有很多必要性。首先，知道有人會檢查你的代碼，提交寫得不好的代碼可能會辜負你的隊友。那些難以維護，或未經測試的代碼是一種壓力。第二，代碼審查也提供了評審和相互學習編寫更好代碼的機會。

代碼審查更容易接觸到其他工程團隊成員，評論也有很多促進作用：

a）增進一段時間內審查代碼的責任感；

b）允許團隊成員——特別新手——觀摩別人的好代碼；

c）加快最佳編碼實踐的傳播。

有種說法，靈活的團隊沒多少時間花費在代碼審查而忽視了技術債務，可以很容易地從寫得不好的代碼積累。 Ooyala公司，在創業早期就為了完成盡可能多的功能而忽略代碼審查;其結果是，雖然最初的產品更迅速地擁有了市場，但代碼修改變得很痛苦，我們花了一年多時間僅僅是改寫脆弱的代碼，以償還技術債務。

谷歌預先對所有的代碼進行審查，但規模較小的團隊並不需要那麼全面和嚴格，因為不是所有的代碼都需要使用相同的標準審查。 Ooyala公司後來採取了措施——通過電子郵件通知核心處危險的變化。在Quora，我們用Phabricator對所有的代碼進行審查，大多後提交，並採用了不同的標準模型，比如控制器代碼和視圖代碼; 對於敏感的代碼或新工程師的代碼，我們要麼做預提交的評論或試圖在幾個小時內去被提交的代碼中查看它們。

Spotify Engineering Culture part 1 (Agile Enterprise Transition with Scrum and Kanban)

5、保持一個相互尊重的工作環境

同事之間的尊重構成開放交流的基礎。靠譜的想法往往通過大家的辯論獲得，這種挑戰也是令人感覺很舒服的方式。人們不爽的是重要反饋沒有及時回應。

1948年，亞歷克斯·奧斯本概述了過去幾十年中在工作環境中流行的方法：參與者走到一起，拋開批評和負面的反饋，共同凝聚在一起不用擔心被評判，頭腦風暴會議。最近的心理學研究已經開始推翻奧斯本的做法，表明在頭腦風暴會議中，鼓勵辯論實際上避免了群體思維並產生了更有效的思路。鑒於這一研究，一個相互尊重的環境變得更加重要，攻擊僅僅是觀點上的而不是針對個人。

工程往往跨越廣泛的領域（系統，機器學習，產品等），而不是每個人在每個領域都有相同的專業知識。其實一個強大的團隊應該具備：在某些領域都有能幹的牛人，即使他們最終會被替代。這有時很麻煩，讓一個系統工程師來評估產品工程師的能力，但在一個健康的工程師文化中，尊重這些差異很重要，而不是完全根據自己的優勢來判斷。

6、建立共享代碼所有權

雖然有些人很自然地就精通代碼庫或基礎設施的各個部分，但沒有一個人可以覺得他們擁有其中任何一件或者是某一件的唯一維護者。雖然有人能在一些領域成為專家，在短期內有成效，但這種做法最終傷害長期利益。

在組織上，共享代碼所有權提供了三個好處。

首先，保持因子8大於1可以減輕壓力和降低團隊維護者離開的風險。這也使人很難在休息時間無憂。我清楚記得，當我在夏威夷火山上徒步旅行度假時，得到報警，因為我是公司的日誌處理器的唯一維護者。

其次，共享所有權讓工程師不限制在特定區域，以促進新的見解。它讓工程師們從某些項目上解放出來，並鼓勵他在多樣的項目上工作，這有助於保持工作的趣味性，並提升員工學習的積極性。從長遠來看，它降低了組織風險——一些工程師一旦感到停滯將會決定離開。

第三，共享所有權還設置了多個團隊成員聚焦在高優先級的問題上（敏捷開發的一種），為更迅速地完成戰略目標奠定了基礎。而孤立的所有權，責任通常落在一兩個人肩上。

很多工程組織犯的錯誤是為時過早地將整個團隊分成子團隊。子團隊會形成責任的阻礙，並很難去打破所有權的牆，因為個人可能會被其子團隊的目標進行評估。 Ooyala有很多小團隊，我很珍惜與一些其他團隊的工作機會;他們使用敏捷開發，重心放在共享代碼所有權，使得工作幸福感和生產力更佳。在Quora的初期，我喜歡的一個方面是這裡更強調項目而不是團隊，讓我有機會合作很多不同項目：從用戶增長，機器學習，工具，推薦，分析，網站的速度，和垃圾檢測都有。

7、投資自動化測試

單元測試和整合測試覆蓋率是管理一個大的代碼庫與一大群人或產品的唯一可擴展的方式。自動化測試提供了對提高代碼質量的大規模重構的信心和有意義的保護。缺乏嚴格的自動化測試，需要手動測試無論是對工程團隊還是外包測試團隊，都是令人害怕的，很容易形成恐懼改善代碼的文化，因為它有可能破壞原有代碼秩序。

在實踐中，自動化測試是對持續佈署工作團隊成長的要求。代碼庫規模隨著時間的推移增長，但熟悉的代碼庫的數量會隨團隊成員新人加入而減少。測試和驗證最容易被原代碼作者完成，因為在他們腦子里還是清晰的，而不是稍後幾個月或幾年才嘗試修改代碼的人。鼓勵單元測試是讓作者為自己的工作負責。

8、分配20％的時間

Gmail是保羅·布赫海特的20％的項目，第一個版本在一天搞定。谷歌新聞，谷歌公交，和谷歌建議也是推出的20％的項目。我用20％的時間，在谷歌寫一個Python框架，使得它更容易建立搜索頁面演示。而谷歌的20％的時間在創業初期可能降低生產力，但是讓工程師們花20％的時間在做某件事情而不是他們的固有的產品規劃，仍然是小型工程組織的創新搖籃。

Ooyala公司沒有正式的20％的時間，但我花了一些，寫了一個命令行構建工具Flex和ActionScript，加快了團隊構建時間。正當Adobe的Flex Builder工具降級之時我完成了它，在工程團隊超過兩倍大小時該工具仍然在使用。 Atlassian公司在嘗試一年後通過20％的時間。Facebook和Ooyala公司後來又增加了一個20%時間：是週期性的黑客比賽——規則是，你可以做任何東西，除了你的正常項目的工作

。

自上而下對產品進行規劃，對公司的總體方向是重要的，不能指望從工程師中冒出很多的想法。只有工程師對他們20％的時間和專注的項目有負責任的態度，這些項目有很大的向前發展的可能。沒有官方的20％的時間，它仍然是可能的，但是對工程師和設計師來說有可能去嘗試瘋狂的想法——也基本上都找週末或假期做。

9、建立學習和持續改進的文化

持續學習和得到充分的挑戰是必須的，因為心理學教授米哈里·米哈伊稱所謂的「心流」表明，一個人完全集中在他們做的事情上，甚至會忘記了時間。但直接即時的反饋能夠適應更快的迭代。

每周技術會議為工程師分享他們的設計或正做的項目創造了一個機會，工程師們為他們的工作感到自豪，並學到了更多工作以外的內容。內部文檔記錄電子郵件服務的工作原理或如何讓排名改變搜索服務，讓工程師學習和探索新的東西，也很好地補充了20％的時間。在Quora，我們通過內部運行Quora去問產品和發展有關的問題。

建設學習文化的一個辦法是注重指導和培訓，以確保每個人都掌握基本的算法，系統和產品成功所必需的技能。工程組織的成長，花在招聘（尤其是高校招聘）越多，需要投入到指導和培訓的努力也要更多。一個導師每天花1個小時來指導新員工前4周工作似乎是很大負擔，但投資是總時間不到一年的1％，這也是決定新員工是否成功的關鍵。

10、招最好的人

雇傭最好的人是以上列出的所有方法的基礎。如果你認為自己是一個B級工程師很難有人尊重。如果你不信任他們開發產品的能力，很難給別人自主權去開發產品。如果沒有足夠的工程經驗，很難識別正確的抽象去構建系統。這很容易陷入構建複雜結構的陷阱，又沒有其他聰明人來挑戰你的想法和推動你走向簡單正確的道路。

在矽谷的史蒂夫·賈伯斯曾說，"A等人聘請A等隊員。 B等人聘請C等人。"關注招募和雇傭合適的人很難，但這對工程組織有效增長很關鍵。黃易山，是前Facebook一個工程經理和總監，認為招聘必須是工程組織的首要任務，不只是管理者，工程師也如此。他也正確地指出「雇傭最好的」和「雇用你面試過的最佳人選」的區別。