怎樣建設(shè)一個(gè)好的工程師文化

我最喜歡的一個(gè)面試問題是，在上家公司的工程師文化里，什么是你最喜歡的，什么是你最不喜歡的。

經(jīng)歷了數(shù)百個(gè)面試之后，這道面試題讓我知道了，什么文化是優(yōu)秀工程師追求的，什么是他們想避開的。我也總結(jié)了自己在google，Ooyala，Quora的六年工作經(jīng)歷，提煉出了一些營(yíng)造好的工程師文化的原則：

1.優(yōu)化迭代速度

快速迭代能讓人鼓足干勁，使人興奮。在面試中，被問到為什么離開上家公司，工程師最常提到的是基礎(chǔ)設(shè)施的缺乏和官僚主義阻礙了快速開發(fā)和發(fā)布，這讓他們非常沮喪。

組織良好的快速迭代，意味著工程師和設(shè)計(jì)師有更大的靈活性和自主權(quán)去做一些日常的決策，而不用事事都得請(qǐng)示。我在google的時(shí)候，搜索結(jié)果上任何的用戶可見的改變，甚至是低訪問量的實(shí)驗(yàn)，都必須在每周的UI review上獲得google副總裁Marissa Mayer的許可。無可置疑，這樣可讓google保護(hù)他的搜索品牌，但這這也明顯阻礙了創(chuàng)新。優(yōu)化迭代速度，也意味著有組織的很好的發(fā)布產(chǎn)品流程，以便在出現(xiàn)意外時(shí)及時(shí)回退。

在基礎(chǔ)架構(gòu)方面，快速迭代意味著持續(xù)快速的開發(fā)；高的測(cè)試覆蓋率來減少編譯和部署時(shí)的錯(cuò)誤；快速的單元測(cè)試；快速的增量編譯和重新加載。特別值得一提的是，持續(xù)部署，將提交的代碼立刻部署到生產(chǎn)環(huán)境中。在Quora剛使用這種方式時(shí)，我難以適應(yīng)，我無法打消它帶來的風(fēng)險(xiǎn)要大過它帶來的益處的念頭，尤其是對(duì)小team。但人們很樂于這樣修改bug，因?yàn)樗械拇a改變都可以實(shí)時(shí)的在線上看到。比起一周或是一個(gè)月提交一次代碼分支來說，這種小的提交窗口更容易定位代碼中的錯(cuò)誤。

團(tuán)隊(duì)智慧，快速的迭代意味著得有一群強(qiáng)有力的leader去協(xié)調(diào)和驅(qū)動(dòng)團(tuán)隊(duì)。一個(gè)決策的相關(guān)人，需要能有效的做出決定并執(zhí)行它。借用Bill Walsh（帶領(lǐng)49人隊(duì)三進(jìn)超級(jí)碗的教練）的一句話，有力的領(lǐng)導(dǎo)需要“分派”、“爆發(fā)”、“恢復(fù)”，這是說，規(guī)劃一個(gè)攻擊計(jì)劃，執(zhí)行它，然后處理結(jié)果。一個(gè)被猶豫不決拖累的團(tuán)隊(duì)，將會(huì)導(dǎo)致個(gè)人努力的白費(fèi)。

2. 無情的推進(jìn)自動(dòng)化

Instagram的聯(lián)合創(chuàng)始人Mike krieger在《Scaling Instagram》的講座中談到，“為減少操作負(fù)擔(dān)而優(yōu)化”是他13個(gè)人的團(tuán)隊(duì)，在產(chǎn)品擴(kuò)展到千萬(wàn)用戶中，學(xué)到的關(guān)鍵一課?？梢杂糜脩艉凸こ處煹谋嚷?，或者產(chǎn)品和工程師的比率，來量化減少操作負(fù)擔(dān)的程度。例如，在facebook，眾所周知，每個(gè)工程師可以支持1百萬(wàn)用戶。

自動(dòng)化解決方案和可重復(fù)腳本任務(wù)是非常重要的，因?yàn)樗麄兛梢园压こ處焾F(tuán)隊(duì)的精力解放出來，放在真正的產(chǎn)品上。當(dāng)服務(wù)有故障時(shí)可以自動(dòng)重啟，在訪問高峰時(shí)，服務(wù)可以很方便和容易的復(fù)制，這些都是在管理復(fù)雜的伸縮性問題上，唯一可靠的方式。比起有遠(yuǎn)見的團(tuán)隊(duì)采用自動(dòng)化方式，短視的團(tuán)隊(duì)更容易受到誘惑，用手工方式解決問題。

Etsy的座右銘“量化任何事情，量化每件事情（measure anything， measure everything）”，和他支持的開源監(jiān)控和圖表工具graphite和statsd，都強(qiáng)調(diào)了自動(dòng)化的另一個(gè)重要方面——自動(dòng)化必須被數(shù)據(jù)和監(jiān)控驅(qū)動(dòng)。如果沒有監(jiān)控和記錄去獲取事件，如何發(fā)生，為什么出錯(cuò)的話，自動(dòng)化是非常困難的。由上面的話可以推導(dǎo)一個(gè)更好的座右銘“量化任何事情，量化每件事情，自動(dòng)化所有可以自動(dòng)化的?！?/p>

3. 構(gòu)造正確的軟件抽象

MIT教授Daniel Jackson點(diǎn)破了好的軟件抽象的重點(diǎn)：先看好的那些抽象，程序?qū)⒆裱O(shè)計(jì)的本質(zhì)；模塊有小而簡(jiǎn)單的接口；新的功能很容易放進(jìn)去，而不需要經(jīng)過額外的重組。再看壞的那些，程序變成了一系列令人不快的驚訝；接口將變得怪異復(fù)雜而且笨拙，就像他們是被強(qiáng)塞進(jìn)接口里一樣，一些最簡(jiǎn)單的改動(dòng)也會(huì)變的異常復(fù)雜。

由工程師構(gòu)造的可伸縮性系統(tǒng)，在google其中的代表是非常聰明的工程師Jeff Dean和 Sanjay Ghemawat構(gòu)造的萬(wàn)能抽象，如：MapReduce，SSTable，protocol buffers，諸如此類。而在Facebook，工程師做所的橫向擴(kuò)展的工作集中在小一些的核心抽象上，例如Thrift，Scribe，Hive。而Quora 做的Webnode和Livenode是相當(dāng)容易理解和在此之上開發(fā)的。

保持核心抽象簡(jiǎn)單和通用，能夠減少客戶化的需求，增加團(tuán)隊(duì)的熟悉和精通程度。一些流行的健壯的系統(tǒng)像Memcached，Redis，MongoDB之類，減少了建造自有存儲(chǔ)和緩存系統(tǒng)的需求。聚焦團(tuán)隊(duì)的注意力在少數(shù)幾個(gè)核心抽象上，要好于分散到很廣的面上，這意味著通用組件更加健壯，監(jiān)控也更加的智能，行為特征更容易被理解，而且測(cè)試也會(huì)更加全面。所有這些都幫助實(shí)現(xiàn)一個(gè)更加簡(jiǎn)單的，能降低操作負(fù)擔(dān)系統(tǒng)。

4. 保持高品質(zhì)的代碼和code reviews

維持高質(zhì)量的代碼能夠提升整個(gè)開發(fā)團(tuán)隊(duì)的生產(chǎn)效率。 整潔的代碼更容易被理解，更快的在此基礎(chǔ)上開發(fā)，更可靠的變更，更少的引入bug。一個(gè)健康的code review過程使這些成為可能。

建立一個(gè)適時(shí)的code review過程，無論是預(yù)提交（pre-commit）或者是后提交（post-commit），都能在多個(gè)方面提升代碼質(zhì)量。知道你的代碼會(huì)被同行檢查，會(huì)帶來很大的壓力，避免寫出難以理解的代碼，沒有測(cè)試的代碼等等。第二，code review提供了一個(gè)很好的機(jī)會(huì)，可以彼此學(xué)習(xí)優(yōu)秀的代碼。

如果這個(gè)code reviews是很容易被團(tuán)隊(duì)中的其他成員訪問到的。那么這種review也能帶來好處：a）提升了復(fù)查代碼的責(zé)任心。b） 允許團(tuán)隊(duì)成員，特別是新成員，模仿好的代碼review。加速好的編碼風(fēng)格的傳播。

反對(duì)意見認(rèn)為，敏捷團(tuán)隊(duì)沒有時(shí)間做code review；這種想法忽視了垃圾代碼堆積，造成技術(shù)債的情況。在Ooyala早期創(chuàng)業(yè)的日子，為了盡可能多的開發(fā)各種功能，我們沒有做code review。這樣雖然讓產(chǎn)品快速推向市場(chǎng)，但是產(chǎn)品代碼維護(hù)起來變得非常的痛苦，為了剔除這個(gè)技術(shù)債，我們又花了整整一年時(shí)間來重寫代碼！！

像google這樣的大公司，會(huì)對(duì)所有的代碼做提交前代碼審查（code review），不過小團(tuán)隊(duì)不必如此嚴(yán)格，至少?zèng)]必要對(duì)所有代碼都如此嚴(yán)格。Ooyala后來對(duì)核心和風(fēng)險(xiǎn)性高的代碼，采用了post-commit代碼審查。在Quora，我們用Phabricator做代碼審核，其中大多數(shù)使用post-commit，對(duì)不同的模塊采用不同的審核標(biāo)準(zhǔn)，對(duì)敏感代碼，對(duì)新工程師，我們也采用per-commit代碼審核，在他們提交代碼前數(shù)小時(shí)。

5. 保持一個(gè)尊重的工作環(huán)境

彼此間的尊重會(huì)促進(jìn)溝通。一個(gè)可以挑戰(zhàn)任何人觀點(diǎn)的地方，一定是一個(gè)可以產(chǎn)生好主意的地方。一個(gè)容易被攻擊的地方，是會(huì)抑制反饋的。

在過去的幾十年里，頭腦風(fēng)暴（Alex Osborn 在1948年創(chuàng)立）風(fēng)靡于工作場(chǎng)合，同事們聚集在一起，放棄批評(píng)和負(fù)面情緒，不用擔(dān)心被評(píng)價(jià)，提出各種創(chuàng)造性的想法。充滿敬意，推遲評(píng)價(jià)是頭腦風(fēng)暴的關(guān)鍵。但最近的心理學(xué)研究，正在顛覆Osborn的方法，新的研究鼓勵(lì)在頭腦風(fēng)暴中爭(zhēng)論，這樣實(shí)際上能避免團(tuán)隊(duì)思想的僵化，從而產(chǎn)生更有效率的想法。根據(jù)這個(gè)理論，一個(gè)尊重的環(huán)境，能夠產(chǎn)生更好的主意。

工程的領(lǐng)域一般都很廣（系統(tǒng)，機(jī)器學(xué)習(xí)，產(chǎn)品等等），不是每一個(gè)人在每一個(gè)領(lǐng)域都有相同的經(jīng)驗(yàn)。實(shí)際上一個(gè)強(qiáng)有力團(tuán)隊(duì)里的每個(gè)人都應(yīng)給在某個(gè)領(lǐng)域很強(qiáng)，即使在其他領(lǐng)域可能很弱。一個(gè)系統(tǒng)工程師不應(yīng)該和一個(gè)產(chǎn)品工程師放在一起評(píng)估，在一個(gè)健康的工程師團(tuán)隊(duì)里，這是很重要的，尊重彼此的差異，不用單純用一方的強(qiáng)項(xiàng)去評(píng)判另一方。

6. 建立共享代碼所有權(quán)

沒有人對(duì)代碼的某部分熟悉后，就覺得他應(yīng)該獨(dú)自擁有或是維護(hù)這段代碼。在短期內(nèi)，某個(gè)人成為產(chǎn)品某個(gè)部分的專家，在一年或更長(zhǎng)的時(shí)間里也許會(huì)提升效率，但長(zhǎng)期來看，這種方式最終會(huì)帶來傷害。

有組織的共享代碼，會(huì)帶來三個(gè)好處。第一，保持公開，能夠更好的減低維護(hù)者的壓力，也能夠降低維護(hù)者離職，給團(tuán)隊(duì)帶來的風(fēng)險(xiǎn)。這也讓無憂無慮的休假變得不那么困難。我不會(huì)忘記，在我獨(dú)自維護(hù)Ooyala 的日志處理系統(tǒng)的時(shí)候，有次我在夏威夷穿越，結(jié)果不斷的收到報(bào)警短信的那些日子。

第二、共享所有權(quán)，能幫助那些沒能參與某個(gè)領(lǐng)域的工程師，擴(kuò)展新鮮視野。而且這樣也可以避免工程師有“我必須扎根一個(gè)項(xiàng)目”的想法，可以鼓勵(lì)他們參與多個(gè)項(xiàng)目。這個(gè)可以幫助保持工作興趣，增進(jìn)雇員不斷學(xué)習(xí)和保持動(dòng)力。長(zhǎng)期來看這樣也可以降低工程師感到停滯而辭職的風(fēng)險(xiǎn)。

第三，共享代碼還有這樣一個(gè)功能，當(dāng)有一個(gè)戰(zhàn)略級(jí)的目標(biāo)需要更快速的完成時(shí)，多個(gè)團(tuán)隊(duì)成員可以云集在一個(gè)高優(yōu)先級(jí)的問題上，優(yōu)先解決它。如果私密化代碼，那么責(zé)任只能落在一兩個(gè)人身上。

一個(gè)工程師團(tuán)隊(duì)容易犯得的錯(cuò)誤是：在整個(gè)team不大的時(shí)候，就把團(tuán)隊(duì)分成了若干子團(tuán)隊(duì)。子團(tuán)隊(duì)會(huì)壘砌一堵墻，妨礙共享代碼，因?yàn)槊總€(gè)人會(huì)受到子團(tuán)隊(duì)目標(biāo)的影響。Ooyala在我在的時(shí)候，就分了小團(tuán)隊(duì)，這使我失去了和另一個(gè)團(tuán)隊(duì)的人一起工作的機(jī)會(huì)，對(duì)此我非常遺憾。因?yàn)槟莻€(gè)團(tuán)隊(duì)采用了一種敏捷開發(fā)方法，他們很關(guān)注共享代碼所有權(quán)，我聽說這給工作滿意度和工作效率帶來了很大的提升。而我熱愛Quora的一個(gè)重要方面，就是我們強(qiáng)調(diào)項(xiàng)目屬于整個(gè)團(tuán)隊(duì)，這讓我有機(jī)會(huì)參與，用戶增長(zhǎng)，機(jī)器學(xué)習(xí)，監(jiān)督工具，推薦，分析，站點(diǎn)提速，垃圾判斷等項(xiàng)目。

7. 在自動(dòng)化測(cè)試上投資

單元測(cè)試加集成測(cè)試，是那些大型的，產(chǎn)品相對(duì)穩(wěn)定的團(tuán)隊(duì)，僅可用的控制大型代碼質(zhì)量的方法。而對(duì)于那些為了提高代碼質(zhì)量進(jìn)行的大規(guī)模的重構(gòu)，自動(dòng)化測(cè)試可以提供一種可靠的保護(hù)。如果缺乏嚴(yán)格的自動(dòng)化測(cè)試，那么用工程師團(tuán)隊(duì)自己測(cè)試，或者聘用外包團(tuán)隊(duì)測(cè)試，時(shí)間成本都會(huì)變得很高。而且這樣容易陷入一種害怕通過重構(gòu)提升代碼質(zhì)量的不良文化。

在實(shí)踐中，自動(dòng)化測(cè)試伴隨著團(tuán)隊(duì)的成長(zhǎng)，需要不斷的開發(fā)。代碼數(shù)量隨著的產(chǎn)品的成長(zhǎng)在不大增大，但是由于新人的加入，團(tuán)隊(duì)成員對(duì)代碼的熟悉程度卻在降低。對(duì)工程師對(duì)代碼還有印象的時(shí)候進(jìn)行測(cè)試，比起幾個(gè)月或幾年后再進(jìn)行測(cè)試要容易的多。所以鼓勵(lì)加強(qiáng)單元測(cè)試的文化，能讓作者更有責(zé)任感，能保證產(chǎn)品質(zhì)量。

8. 自由支配 20% 的時(shí)間

Gmail來自于Paul Buchheit的20%項(xiàng)目，他第一版的開發(fā)時(shí)間加一起不超過一天。Google News，Google Transit，Google Suggest 也都開始于20%項(xiàng)目。我在google的時(shí)候，用20%的時(shí)間，寫了一個(gè)python框架，它能夠很容易的搭建一個(gè)搜索頁(yè)面原型。雖然現(xiàn)在google20%時(shí)間的效率可能比早期低了，但是這種觀念，容許工程師花費(fèi)20%的工作時(shí)間在其他項(xiàng)目上的觀念，依然會(huì)是小工程師團(tuán)隊(duì)創(chuàng)新的搖籃。

Ooyala沒有官方的20%時(shí)間，至少我在的時(shí)候沒有，但是我仍然想辦法，寫了一個(gè)命令行Flex和Actionscript編譯工具，它能提高團(tuán)隊(duì)編譯的時(shí)間，其實(shí)就是一個(gè)Adobe's Flex Builder工具的降級(jí)版本。雖然現(xiàn)在工程師團(tuán)隊(duì)已經(jīng)增長(zhǎng)了三倍，但是這個(gè)工具仍然在被使用。Atlassian在嘗試了一年以后，正式才用了20%時(shí)間。 有個(gè)facebook創(chuàng)立的20%時(shí)間的變種，Ooyala后期也采用它，是周期性的hackathons，--整夜的干，規(guī)則就是你可以干任何事情，除了你的本職項(xiàng)目。

從上到下的指定計(jì)劃的方式，在關(guān)注整個(gè)公司的方向的時(shí)候是非常必要的，但是不適合管理眾多的來自緊貼現(xiàn)實(shí)的工程師的創(chuàng)意。只要工程師負(fù)責(zé)的對(duì)待20%的時(shí)間，并且專注在那些可能產(chǎn)生重大影響項(xiàng)目上，那么這個(gè)過程中可能會(huì)產(chǎn)生重大的進(jìn)步。沒有官方認(rèn)可的20%時(shí)間，這些仍然是可能的，但是更加的困難，設(shè)計(jì)和工程師想去實(shí)現(xiàn)那些瘋狂的想法，就必須要犧牲周末和假期的時(shí)間了。

9. 建立一種持續(xù)學(xué)習(xí)提高的文化

學(xué)習(xí)和有足夠的挑戰(zhàn)，是心理學(xué)教授Mihaly Csikeszentmihalyi所說的達(dá)到“FLOW”所需要的要素，在“flow”里人們關(guān)注他們所做的事情，并且被它激勵(lì)著，甚至都忘記了時(shí)間的存在?？焖俚鷰淼闹苯臃答佈h(huán)是達(dá)到flow的另一要素。

每周的技術(shù)講座，為工程師提供了一個(gè)論壇分享他們的設(shè)計(jì)，他們的構(gòu)建，也為工程師提供了一個(gè)為自己工作感到自豪的機(jī)會(huì)，而且這樣也能讓其他工程師學(xué)到他們領(lǐng)域以外的知識(shí)。內(nèi)部（知識(shí)管理系統(tǒng)），諸如，email系統(tǒng)如何工作，搜索服務(wù)如何排序等，也能鼓勵(lì)工程師學(xué)習(xí)和發(fā)布他們掌握的知識(shí)，以及更好的完成20%的時(shí)間。在Quora，我們跑了一個(gè)內(nèi)部的Quora服務(wù)來做這個(gè)事情，在上面我們提一些產(chǎn)品或開發(fā)的相關(guān)問題。

建設(shè)學(xué)習(xí)文化的目的，是通過教育和訓(xùn)練，確保每一個(gè)人都具備做好工作所需要的“基本算法”、“系統(tǒng)”、“產(chǎn)品”等技能。隨著工程師團(tuán)隊(duì)的成長(zhǎng)，團(tuán)隊(duì)會(huì)把越多的精力放在招聘上（尤其是校園招聘），那么，就需要更多的在指導(dǎo)和訓(xùn)練上投資。在新雇員到來的頭四個(gè)星期，導(dǎo)師每天花一個(gè)小時(shí)來輔導(dǎo)，這可能對(duì)導(dǎo)師來說是一個(gè)負(fù)擔(dān)，但是，這個(gè)只花費(fèi)了導(dǎo)師一年工作時(shí)間的1%的投資，會(huì)有顯著的杠桿效用，這會(huì)決定，新雇員是否會(huì)取得成功。

10. 雇傭最好的

雇傭最好的，是實(shí)現(xiàn)以上各項(xiàng)的基礎(chǔ)。如果你認(rèn)為你的工程師是B級(jí)人物，那么你就很難尊敬每個(gè)人。如果你不信任他們?cè)诋a(chǎn)品上的直覺，那么就很難給每個(gè)人以自主權(quán)。如果沒有充足的經(jīng)驗(yàn)，就能難正確抽象，構(gòu)建基礎(chǔ)模塊。如果沒有其他人挑戰(zhàn)的方案，驅(qū)使你更加簡(jiǎn)化，你就容易陷入復(fù)雜的陷阱。

在硅谷，流傳著一句喬布斯創(chuàng)造的一句話“A等角色雇傭A等角色。B等角色雇傭C等角色?！本劢乖谡心己凸蛡蛘_的人，是很難，但是對(duì)團(tuán)隊(duì)的成長(zhǎng)是很關(guān)鍵的。黃一山（Yishan Wong）前facebook工程經(jīng)理和總監(jiān)，談到雇人是團(tuán)隊(duì)中每個(gè)人的第一優(yōu)先級(jí)的工作，不只是對(duì)經(jīng)理而言。他也很好的解釋了“雇傭最好的”和“雇傭你面試的人里最好的”之間的差別。

在Ooyala早期，我們被接踵而來的客戶需求工作淹沒，所以我們不得不降低我們的雇傭標(biāo)準(zhǔn)，以便能雇傭的足夠的人手幫我們完成工作。我真的希望，我們沒有這么做，這些低質(zhì)量代碼欠下的技術(shù)債和team中差勁的工程師最終傷害了team和產(chǎn)品。

營(yíng)造好的工程師文化是一系列的工作，但是這事非常值得去做的。