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

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

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

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

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

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

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

2. 無情的推進自動化

Instagram的聯(lián)合創(chuàng)始人Mike krieger在《Scaling Instagram》的講座中談到，“為減少操作負擔而優(yōu)化”是他13個人的團隊，在產品擴展到千萬用戶中，學到的關鍵一課。可以用用戶和工程師的比率，或者產品和工程師的比率，來量化減少操作負擔的程度。例如，在facebook，眾所周知，每個工程師可以支持1百萬用戶。

自動化解決方案和可重復腳本任務是非常重要的，因為他們可以把工程師團隊的精力解放出來，放在真正的產品上。當服務有故障時可以自動重啟，在訪問高峰時，服務可以很方便和容易的復制，這些都是在管理復雜的伸縮性問題上，唯一可靠的方式。比起有遠見的團隊采用自動化方式，短視的團隊更容易受到誘惑，用手工方式解決問題。

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

3. 構造正確的軟件抽象

MIT教授Daniel Jackson點破了好的軟件抽象的重點：先看好的那些抽象，程序將遵循設計的本質；模塊有小而簡單的接口；新的功能很容易放進去，而不需要經過額外的重組。再看壞的那些，程序變成了一系列令人不快的驚訝；接口將變得怪異復雜而且笨拙，就像他們是被強塞進接口里一樣，一些最簡單的改動也會變的異常復雜。

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

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

4. 保持高品質的代碼和code reviews

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

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

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

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

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

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

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

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

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

6. 建立共享代碼所有權

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

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

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

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

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

7. 在自動化測試上投資

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

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

8. 自由支配 20% 的時間

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

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

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

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

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

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

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

10. 雇傭最好的

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

在硅谷，流傳著一句喬布斯創(chuàng)造的一句話“A等角色雇傭A等角色。B等角色雇傭C等角色。”聚焦在招募和雇傭正確的人，是很難，但是對團隊的成長是很關鍵的。黃一山（Yishan Wong）前facebook工程經理和總監(jiān)，談到雇人是團隊中每個人的第一優(yōu)先級的工作，不只是對經理而言。他也很好的解釋了“雇傭最好的”和“雇傭你面試的人里最好的”之間的差別。

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

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