如何建設好的工程師文化

　　如何建立一個好的工程師文化，對任何一個技術團隊都是一個挑戰。在我困惑的時候，很有幸看到了quora上的這篇文章。我覺得總結的很全面。我抽空粗粗的翻譯了一下，希望對有同樣困惑的同學有幫助。

　　What makes a good engineering culture?

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

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

　　1.優化迭代速度

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

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

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

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

　　2. 無情的推進自動化。

　　Instagram 的聯合創始人Mike krieger在《Scaling Instagram》的講座中談到，“為減少操作負擔而優化”是他13個人的團隊，在產品擴展到千萬用戶中，學到的關鍵一課?？梢杂糜脩艉凸こ處煹谋嚷?，或者產品和工程師的比率，來量化減少操作負擔的程度。例如，在facebook，眾所周知，每個工程師可以支持1百萬用戶。

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

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

　　3. 構造正確的軟件抽象.

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

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

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

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

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

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

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

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

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

原文轉自：http://www.kjueaiud.com