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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. 在自動化測試上投資

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

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

8. 自由支配 20% 的時間

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

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

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

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

學(xué)習(xí)和有足夠的挑戰(zhàn)，是心理學(xué)教授Mihaly Csikeszentmihalyi所說的達(dá)到“FLOW”所需要的要素，在“flow”里人們關(guān)注他們所做的事情，并且被它激勵著，甚至都忘記了時間的存在。快速迭代帶來的直接反饋循環(huán)是達(dá)到flow的另一要素。

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

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

10. 雇傭最好的

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

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

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

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