Facebook 如何發布代碼 (How Facebook Ships Code 譯文)

　　按：這篇 How Facebook Ships Code 提供了大量的細節信息，之前已經有朋友提供了一個翻譯版本，閱讀之后發現有些許錯誤，并且原文有更新，所以基于前面的翻譯版本我重新翻譯了一個(完整的)版本。一并謝過。希望這個版本對大家也有所參考。

　　我對 Facebook 的運作方式著迷。這是個非常獨特的環境，很難被復制(這個方式并不適合所有的公司，即使有些公司嘗試過這么做)。下面這些筆記來自我和Facebook的許多朋友的交談，關于他們開發、運維與軟件發布等方面。

　　好像很多人都對 Facebook 感興趣… 這家公司的工程師驅動文化(Developer-driven culture)已經被公眾大加研究，并且其它其它公司也在探求是否/如何實現工程師驅動文化。Facebook 的內部流程實在夠神秘，當然，工程師團隊也會發布一些關于新功能以及部分內部系統公開備忘，不過這些大多數是”說明”類的文章(What)，而非講述”機制”(How)… 所以，外部人員很難明白 Facebook 的創新以及如何比其它公司做到更有效的對服務進行優化。我作為外部人員嘗試深入理解 Facebook 的運作，匯集了幾個月來的這些觀察信息。出于對信息來源的隱私保護，我去掉了特定功能/產品的名字。我又等了6個月以后才發布這些記錄，所以，有些信息肯定過時了。我希望發布這些信息會有助于了解 Facebook 的管理機制如何在組織中進行決策的推行而非逐步陷入混輪…很難說這與 Facebook 的成敗或是 Facebook 的產品協作相關。我相信很多面向消費者的互聯網公司會從 Facebook 這個案例受益。

　　*非常*感謝那些幫助我整理這篇文章的 Facebook 內部的朋友們。也要感謝項 epriest 和 fryfrog 這樣的朋友，他們協助我進行對本文進行校正、編輯。

　　記錄：

　　截止到2010年6月，Facebook有將近2000名員工，10個月前只有大約1100人，一年之間差不多翻了一番!

　　工程部和運維部是兩個最大的部門，每個大概都有 400-500人。這兩個部門人數大約占了公司的一半。

　　產品經理(PM)與工程師的比例大約為1-7到1-10。

　　每個工程師入職時，都要接受 4 到 6 周的 “Boot Camp” 培訓，通過修復Bug 和聽更資深的工程師的課程來熟悉 Facebook 系統。每次 Boot Camp 大約有 10% 的人無法完成課程而被淘汰。

　　培訓結束后，每個工程師都可以訪問線上的數據庫【標準課程”能力越大，責任越大” ( “with great power comes great responsibility”) 對此有闡釋，另有一份明晰的”不可觸犯的天條”，比如共享用戶的隱私數據】。

　　[修改, 感謝 fryfrog] “Facebook 有非常牢靠的安全保障，以免有人(你可以想象內部有人有這個權限的)不小心/故意做了些糟糕的的事。如果你已經”成為”了需要別人支持的人，事由將被記錄，并且有謹慎的審計。這里不允許鉆空子。

　　任何工程師都可以修改Facebook的代碼庫，簽入(Check-in)代碼。

　　濃厚的工程師驅動文化。”產品經理基本可以被忽略”，這是Facebook一名員工的話。工程師可以修改流程的細節，重新安排工作任務，隨時植入自己的想法。[評論] “本文的作者是一個產品經理，所以這個論斷引起里我的注意。你看完整篇文章后會發現，很顯然，Facebook 的文化實際上是擁抱產品經理的實踐的，所以，不是產品經理的角色被忽略，而是，這家公司的文化看上去是想讓”每個人”感受到對產品的責任”。

　　在每月的跨部門會議上，由工程師來匯報工作進度，市場部和產品經理會出席會議，也可以做些簡短的發言，但如果長篇大論的話，將如實反饋給他們的主管，”產品人員在上次會議說的太多”。他們確實想讓工程師來主導產品的開發，對自己的產品負責。

　　項目需要的資源都是自發征集的：

　　某個產品經理把工程師們召集起來，讓他們對自己的想法產生興趣。

　　工程師們決定開發那些讓他們感興趣的特性。

　　工程師跟他們的經理說：”我下周想開發這5個新特性”。

　　經理會讓工程師獨立開發，可能有時會讓他優先完成一些特性。

　　工程師獨立完成所有的特性 — 前端 JavaScript/后端數據庫，等等所有相關的部分。如果需要得到設計人員的幫助，需要先讓設計人員對你的想法產生興趣(專職的設計師很少)。請架構師幫忙也是如此。但總體來說，工程師要獨立完成所有的任務。

　　對于某個特性是否值得開發的爭執，通常是這么解決的：花一個星期的時間實現，并在小部分用戶中(如1%的內華達的用戶)進行測試。

　　工程師通常樂衷致力于架構、擴展性以及解決”難題”，那樣能獲得聲望和尊敬。他們很難對前端項目或用戶界面產生太大的興趣。這跟其他業務為導向的公司可能正好相反，那些公司人人都想做客戶能直接接觸到的東西，然后會指著某個特定的用戶體驗說，”那是我做的”。在 Facebook，后端的東西，比如 News Feed 算法、廣告投放算法、Memcache 優化等等，是工程師真正傾慕的項目。

　　News Feed 因為太重要了，扎克會親自審查任何變動。這是個特例。

　　[更正, 感謝 epriest ]“所有的代碼變更都要經過強制性的代碼審查(比如一個或者多個工程師)。我相信這篇文章只是說 扎克并不自己審查每一個變更”。

　　[更正, 感謝 fryfrog ]“所有的修改至少要被一個人審查，而且這個系統可以讓任何人很方便地審核其他人的代碼，即使你沒有邀請他。提交未經審查的代碼，將被視為惡意行為”。

　　工程師負責測試、Bug 修復以及啟動對自己項目的維護。有單元測試和集成測試的框架可用，但很少使用。

　　[更正, 感謝 fryfrog ] “補充一下，我們是有 QA 的，只是沒有正式的 QA 組而已。每個辦公室或通過VPN連接的員工會使用下一版的 Facebook，這個版本的 Facebook 會經常更新，通常比公開的早 1-12 小時。所有的員工被強烈建議提交 Bug，而且通常會很快被修復”。

　　回復：很奇怪只有很少的 QA 或自動測試 — “大部分工程師都能寫出基本沒有bug的代碼，只是在其他公司他們不需要這么做。如果有 QA 部門，他們只要把代碼寫完，扔給他們就行了” [編輯：請注意這是很主觀的，我選擇包括這部分內容是因為這和那些其它公司的標準開發實踐完全相反]

原文轉自：http://dbanotes.net/arch/facebook_how_facebook_ships_code.html