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