打造團(tuán)隊的工程師文化需要做好10件事：1. 優(yōu)化迭代速度?？焖俚乃俣忍岣吡斯ぷ鞣e極性和興奮度。一些工程師在面試時對他們?yōu)槭裁匆x開公司列舉了最常見的令人沮喪的原因是基礎(chǔ)設(shè)施和繁冗流程阻礙他們部署代碼或者上線功能。在組織上，快速迭代意味著給工程師和設(shè)計師的靈活性和不設(shè)限自主做日常決策。我在谷歌，任何用戶可見的搜索結(jié)果改變，即使是低流量的實驗，需要瑪麗莎梅耶在 每周 UI 審查批準(zhǔn)。雖然這允許谷歌保護(hù)它的搜索的品牌，但它明顯阻礙創(chuàng)新。優(yōu)化迭代速度也意味著，有明確定義的流程推出產(chǎn)品，而不會說花了大量時間投入后意外發(fā) 生。優(yōu)化迭代速度意味著建立持續(xù)部署以快速驗證，提高測試覆蓋率，減少構(gòu)建和網(wǎng)站當(dāng)機(jī)次數(shù)，快速單元測試，并鼓勵大家來運(yùn)行，快速增量編譯 和重新加載，以縮短開發(fā)時間。持續(xù)部署，提交馬上到線上特別重要。 迭代速度至少在小工程隊利大于弊（線上出錯的風(fēng)險）。人們更興奮看到功能和修復(fù) Bug 是因為很快看到實時流量變化。這要比超過一周或成批的代碼提交，要更容易推斷和精確定位錯誤源的位置。團(tuán)隊智慧，快速迭代的速度意 味著有強(qiáng)有力的領(lǐng)導(dǎo)者，幫助協(xié)調(diào)和推動團(tuán)隊的工作。在決定關(guān)鍵點(diǎn)上負(fù)責(zé)人需要有效地作出決定，并承諾他們的選擇。借用比爾 · 沃爾什，一個領(lǐng)導(dǎo) 49 人隊 3 次進(jìn)超級碗的一句話，強(qiáng)有力的領(lǐng)導(dǎo)者需要 “承諾，引爆，恢復(fù)”，這意味著承諾攻擊計劃，執(zhí)行它，然后看反應(yīng)結(jié)果。優(yōu)柔寡斷團(tuán)隊只會導(dǎo)致個人努力白費(fèi)。2. 盡量自動化。在技術(shù)講座 “規(guī)?；?Instagram”，Instagram 的聯(lián)合創(chuàng)始人邁克 · 克里格引 “優(yōu)化最少的操作負(fù)擔(dān)” 作為一個重要的教訓(xùn)，領(lǐng)導(dǎo)他的 13 人團(tuán)隊用戶增長到幾千萬。 產(chǎn)品的增長意味每工程師的操作負(fù)擔(dān)加重，如用戶跟工程師或者特定功能跟工程師的比率。 像 Facebook 號稱每個工程師支持超過 100 萬的用戶比例指標(biāo)。自動化解決方案和腳本去重復(fù)執(zhí)行任務(wù)很重要，因為它們解放工程團(tuán)隊，讓他們?yōu)閷嶋H產(chǎn)品工作。確保如有失敗服務(wù)自動重啟和方便快捷在流量高峰期替代是在管理大而復(fù)雜產(chǎn)品的明智方案。在短期內(nèi)可以對應(yīng)用做快速修復(fù)，而長期還是要依賴自動化測試，這需要權(quán)衡。Etsy 的的座右銘 “衡量所有，衡量一切”。支持像開源監(jiān)控和制圖工具 graphite 和 statsd 突出自動化 – 即自動化必須由數(shù)據(jù)和監(jiān)控驅(qū)動。如果沒有監(jiān)控和日志你怎么知道什么事情錯了，為什么錯。自動化是困難的。一個后續(xù)的座右銘是 “衡量所有，衡量一切，并盡可能自動化?！?. 建立合理的軟件抽象。我的麻省理工學(xué)院教授和本科生研究顧問丹尼爾 · 杰克遜說的軟件抽象的重要性：“選擇正確的方式，程序化自然而然地設(shè)計; 模塊化就是有小而簡單的界面; 新功能在不影響全局的情況下產(chǎn)生。要是搞錯的話，程序?qū)⑹且幌盗械挠憛挼目樱航涌诤鼙孔疽驗樗麄儫o法適應(yīng)一些意料之外的交互，即使是最簡單的改動將是很難維護(hù) “。是什么在谷歌讓數(shù)千名工程師建立可擴(kuò)展的系統(tǒng)，是因為他們有非常聰明的工程師像杰夫 · 迪恩和桑杰 · 格瑪沃特創(chuàng)建了簡單，但豐富的抽象，如 MapReduce 的，SSTable，Protocol Buffer 等。是什么讓 Facebook 工程這么支持大規(guī)模，是因為專注于核心，同樣喜歡抽象和簡單，Thrift, Scribe, Hive。是什么讓設(shè)計人員能夠有效構(gòu)建產(chǎn)品，Webnode，Livenode 也是基于同樣的理解。保持核心抽象的簡單和減少自定義解 決方案，并增加團(tuán)隊熟悉度和對專業(yè)知識的抽象。日益普及系統(tǒng)像 Memcached，Redis，MongoDB 等系統(tǒng)都是降低建立定制存儲和緩存系統(tǒng)的必要。團(tuán)隊重點(diǎn)轉(zhuǎn)移到少數(shù)核心抽象，而不是分裂在很多臨時解決方案，讓公共庫更穩(wěn)健，監(jiān)控更智能，性能更易理解， 測試更全面。所有這一切都有助于搭建一個簡單的系統(tǒng)，降低操作負(fù)擔(dān)。4. 注重代碼審查，編寫高代碼質(zhì)量。維持高品質(zhì)的代碼庫增加了整個工程團(tuán)隊的工作效率。清潔代碼更容易便捷發(fā)展和維護(hù)，更適應(yīng)變化，不容易引入錯誤。健康的代碼審查過程使之成為可能。建立及時代碼審查流程，不管是預(yù)提交或提交后，能有幾種方法的提高代碼質(zhì)量。首先，知道有人會檢查你的代碼，提交寫得不好的代碼可能會辜負(fù)你的隊友。那些難以維護(hù)，或未經(jīng)測試的代碼是一種壓力。第二，代碼審查也提供了評審和相互學(xué)習(xí)編寫更好代碼的機(jī)會。代碼審查更容易接觸到其他工程團(tuán)隊成員，評論也帶動了 a）增進(jìn)一段時間內(nèi)審查代碼的責(zé)任感 b）允許團(tuán)隊成員 – 特別新手 – 觀摩別人的好代碼，c）加快最佳編碼實踐的傳播。有種說法，靈活的團(tuán)隊沒多少時間花費(fèi)在代碼審查而忽視了技術(shù)債務(wù)，可以很容易地從寫得不好的代碼積累。 在創(chuàng)業(yè)早期就為了完成盡可能多的功能而忽略代碼審查; 其結(jié)果是，雖然最初的產(chǎn)品更迅速地?fù)碛辛耸袌觯a變得修改痛苦，我們花了一年多時間僅僅是改寫脆弱的代碼，以償還技術(shù)債務(wù)。谷歌預(yù)先進(jìn) 行審查所有的代碼，但規(guī)模較小的團(tuán)隊并不需要那么全面和嚴(yán)格，因為不是所有的代碼需要使用相同的標(biāo)準(zhǔn)審查。 公司后來采用后提交的評論通過電子郵件通知核心處危險的變化。我們用 Phabricator 對所有的代碼審查，大多后提交，并采用了不同的標(biāo)準(zhǔn)模型，比如控制器代碼和視圖代碼; 對于敏感的代碼或新工程師的代碼，我們要么做預(yù)提交的評論或試圖在幾個小時被提交的代碼中查看它們。5. 保持一個尊重的工作環(huán)境。同事之間的尊重構(gòu)成開放交流的基礎(chǔ)?？孔V的想法獲得往往通過大家辯論，這種挑戰(zhàn)也是感覺很舒服的方式。人們不爽的是重要反饋沒有及時回應(yīng)。1948 年，亞歷克斯 · 奧斯本概述了在過去的幾十年中在工作環(huán)境中流行方法，參與者走到一起，拋開批評和負(fù)面的反饋，共同凝聚在一起不用擔(dān)心被評判，頭腦風(fēng)暴會議。最近的心理學(xué) 研究已經(jīng)開始推翻奧斯本的做法，表明在頭腦風(fēng)暴會議，鼓勵辯論實際上避免群體思維并產(chǎn)生更有效的思路。鑒于這一研究，一個尊重環(huán)境變得更加重要使得攻擊僅 僅是觀點(diǎn)而不是個人。工程往往跨越廣泛的領(lǐng)域（系統(tǒng)，機(jī)器學(xué)習(xí)，產(chǎn)品等），而不是每個人都有相同的專業(yè)知識在每個領(lǐng)域。其實是一個強(qiáng)大的團(tuán) 隊?wèi)?yīng)該具備，在某些領(lǐng)域都有能干的牛人，即使他們最終會被替代。這有時很麻煩，讓一個系統(tǒng)工程師來評估產(chǎn)品工程師的能力，但在一個健康的工程師文化中尊重 這些差異很重要，并不是完全根據(jù)自己的優(yōu)勢來判斷。6. 建立共享代碼所有權(quán)。雖然有些人自然就成為精通代碼庫或基礎(chǔ)設(shè)施的各個部分，但沒有一個人應(yīng)該覺得他們擁有或任何一件的唯一維護(hù)者。雖然有個人一年以上能在一些領(lǐng)域成為專家，在短期內(nèi)有成效，這種做法最終傷害長期利益。在組織上，共享的代碼所有權(quán)提供了三個好處。首先，保持因子 8 大于 1 可以減輕壓力和降低團(tuán)隊維護(hù)者離開的風(fēng)險。這也使人很難在休息時間無憂。我清楚記得，當(dāng)我夏威夷火山上徒步旅行度假時候，得到報警，因為我是公司的日志處理器的唯一維護(hù)者。其次，共享所有權(quán)讓工程師不限制在特定區(qū)域，以促進(jìn)新的見解。它讓工程師們從他們被困在某些項目上離開，并鼓勵他在多樣性項目上工作，這有助于保持工作有趣性，并提升員工學(xué)習(xí)積極性。從長遠(yuǎn)來看，它降低組織風(fēng)險，一些工程師感到停滯就會決定離開。第三，共享所有權(quán)還設(shè)置了有多個團(tuán)隊成員（從敏捷開發(fā)的一種技術(shù)）一起在一個高優(yōu)先級的問題，必要時更迅速地完成戰(zhàn)略目標(biāo)奠定了基礎(chǔ)。而孤立的所有權(quán)，負(fù)擔(dān)通常落在一兩個人。很多工程組織犯的錯誤是為時過早將整個團(tuán)隊分成子團(tuán)隊。子團(tuán)隊會形成責(zé)任的阻礙，并很難去打破所有權(quán)的墻，因為個人可能會被其子團(tuán)隊的目標(biāo)進(jìn)行評估。 有很多小團(tuán)隊，我很珍惜與一些其他團(tuán)隊的工作機(jī)會; 他們使用敏捷開發(fā)，重心放在共享代碼所有權(quán)，使得工作幸福感和生產(chǎn)力更佳。 初期我喜歡的一個方面是更強(qiáng)調(diào)項目而不是團(tuán)隊，讓我有機(jī)會合作的項目從用戶增長，機(jī)器學(xué)習(xí)，工具，推薦，分析，網(wǎng)站的速度，和垃圾檢測。7. 投資自動化測試。單元測試和集成測試覆蓋率是管理一個大的代碼庫與一大群人沒有不斷被破壞構(gòu)建或產(chǎn)品的唯一可擴(kuò)展的方式。自動化測試提供了對提高代碼質(zhì)量的大規(guī)模重構(gòu)的信心 和也進(jìn)行有意義的保護(hù)。缺乏嚴(yán)格的自動化測試，需要手動測試無論是對工程團(tuán)隊或外包測試團(tuán)隊，是容易令人害怕的，很容易陷入恐懼改善代碼的文化，只是因為 它有可能破壞以前的。在實踐中，自動化測試是對持續(xù)部署工作團(tuán)隊成長的要求。代碼庫規(guī)模隨著時間的推移增長，但熟悉的代碼庫多少會隨團(tuán)隊成 員新人加入而減少。測試和驗證是最容易被原代碼作者完成，因為在他們腦子里還是清晰的，而不是被稍后幾個月或幾年嘗試修改代碼的人。鼓勵單元測試是讓作者 為自己工作責(zé)任。8. 分配 20％的時間。Gmail 是保羅 · 布赫海特的 20％的項目，第一個版本在一天搞定。 谷歌新聞，谷歌公交，和谷歌建議也是推出的 20％的項目。我用 20％的時間，而在谷歌寫一個 Python 框架，使得它更容易建立搜索頁面演示。而谷歌的 20％的時間在創(chuàng)業(yè)初期可能降低生產(chǎn)力，讓工程師們花 20％的時間做某件事情而不是他們的產(chǎn)品規(guī)劃上，仍然是小型工程組織的創(chuàng)新?lián)u籃。Ooyala 公司沒有正式 20％的時間，我們花了一些時間寫了一個命令行構(gòu)建工具 Flex 和 ActionScript，加快了團(tuán)隊構(gòu)建時間。正當(dāng) Adobe 的 Flex Builder 工具降級時候我完成了它，在工程團(tuán)隊超過兩倍大小時該工具仍然在使用。 Atlassian 公司在嘗試一年后通過 20％的時間。Facebook 后來又增加了一個 20% 時間的變化是周期性的黑客比賽 – 一晚上的事件，規(guī)則是，你可以做任何東西，除了你的正常項目的工作。自上而下的方法對產(chǎn)品的規(guī)劃，對公司的總體方向是重要的，不能指望從工程師中冒出很多的想法。只要工程師對他們 20％的時間和專注于什么可以有很大影響的負(fù)責(zé)，這些項目可能會導(dǎo)致很大的向前發(fā)展。沒有官方的 20％的時間，它仍然是可能的，對工程師和設(shè)計師可能更難去嘗試瘋狂的想法 – 基本上都找周末或假期做。9. 建立學(xué)習(xí)和持續(xù)改進(jìn)的文化。學(xué)習(xí)和得到充分得到挑戰(zhàn)是心理學(xué)教授米哈里 · 米哈伊稱之為 “流”，一個人是如此的完全集中在他們做的事情，他們甚至忘了時間。 直接即時的反饋能夠適應(yīng)更快的迭代周期。每周技術(shù)會議給工程師分享他們的設(shè)計或者正工作的項目，創(chuàng)造了一個機(jī)會，工程師們?yōu)樗麄児ぷ鞲械阶院?，并學(xué)到更多工作以外的范疇。內(nèi)部文檔記錄電子郵件服務(wù)的工作原理或如何讓排名改變搜索服務(wù)，讓工程師學(xué)習(xí)和探索新的東西，也很好地補(bǔ)充了 20％的時間。建設(shè)學(xué)習(xí)文化的一個辦法是注重指導(dǎo)和培訓(xùn)，以確保每個人都掌握基本的算法，系統(tǒng)和產(chǎn)品成功所必需的技能。工程組織的成長，花在招聘（尤其是高校招聘）越多， 更多的努力需要投入到指導(dǎo)和培訓(xùn)。一個導(dǎo)師每天花一個小時為一個新員工的前 4 周工作上似乎是很大負(fù)擔(dān)，但投資是總時間的新員工將在一年內(nèi)花費(fèi)不到 1％，并能幫助到此人是否真正成功。10. 招最好的人。雇傭最好的人是許多其他列出的 基礎(chǔ)。如果你認(rèn)為自己是一個 B 級工程師很難有人尊重。如果你不信任他們開發(fā)產(chǎn)品能力，很難給別人自主權(quán)去開發(fā)產(chǎn)品。如果沒有足夠的工程經(jīng)驗，很難識別正確的抽象去構(gòu)建系統(tǒng)。這很容易陷 入構(gòu)建復(fù)雜結(jié)構(gòu)的陷阱，又沒有其他聰明人來挑戰(zhàn)你的想法和推動你走向簡單正確的道路。在硅谷的史蒂夫 · 喬布斯說，“A 等人聘請 A 等隊員。 B 等人聘請 C 等人?！瓣P(guān)注招聘和雇傭合適的人很難，但這對工程組織有效增長很關(guān)鍵。黃易山，是前 Facebook 一個工程經(jīng)理和總監(jiān)，認(rèn)為招聘必須是工程組織的首要任務(wù)，不只是管理者，工程師也如此。 他也正確地指出 “雇傭最好的” 和 “雇用你面試過的最佳人選” 的區(qū)別在初期，我們在客戶工作上不堪重負(fù)，我們很想降低我們的招聘門檻，這樣我們可以聘請足夠的人來做大量工作。我很高興我們沒有，因為低質(zhì)量的代碼和較弱的工程師團(tuán)隊積累技術(shù)債對團(tuán)隊和產(chǎn)品的傷害是很大的。建立一個良好的工程文化無疑是一個大量的工作，但由此產(chǎn)生的工作環(huán)境是值得的。