搜尋

隨機推薦

01 十一月 2010
23 十一月 2010
28 十一月 2009

Facebook是如何管理代碼的

我對facebook的運轉著迷。 這是一個很獨特的環境,不容易被複製(他們的體係並不適合所有的公司,即使他們努力嘗試過)。 下面是我和facebook的朋友們關於他們如何開發和管理項目的記錄。

現在距離我收集的這些信息又過去6個月了,我相信facebook肯定又對他們的項目開發實踐進行了改進。 所以這些記錄可能會有點過時。 同時facebook的工程師驅動文化也越來越為大眾所知。 非常感謝那些幫助我整理這篇文章的facebook的朋友們。

 

廣告

記錄:

  • 截止到2010年6月,facebook有將近2000名員工,10個月前只有1100名,一年之間差不多翻了一番。
  • 兩個最大的部門是工程師和運維,每個部門大概都是400-500人。 這兩個部門人數大約佔了公司的一半。
  • 產品經理與工程師的比例大約為1-7到1-10。
  • 每個工程師入職時,都要接收4-6週的培訓,通過修補bugs和聽高級開發工程師的課程來熟悉facebook。
  • 培訓結束後,每個工程師都可以接觸線上的數據庫(更大的權力意味著更大的責任,也有一份"勿做清單",不然可能會被開,比如共享用戶的隱私數據)。
  • 有非常牢靠的安全體系,以免有人不小心/故意做了些不好的事。
  • 每個工程師可以修改facebook的任何代碼,隨時可以簽入。
  • 濃厚的工程師驅動文化。 "產品經理基本可以被忽略",這是facebook一名員工的話。 工程師可以修改流程的細節,重新安排工作任務,隨時植入自己的想法。
  • 在每月的跨部門會議上,由工程師來匯報工作進度,市場部和產品經理會出席會議,也可以做些簡短的發言,但如果說得太多,很可能就會被打小報告。 他們確實想讓工程師來主導產品的開發,對自己的產品負責。
  • 項目需要的資源都是自願的
    • 一個產品經理把工程師們召集到一起,讓他們對他的想法產生興趣。
    • 工程師們決定開發那些讓他們感興趣的特性。
    • 工程師跟他們的經理說:"我下週想開發這5個新特性"。
    • 經理會讓工程師獨立開發,可能有時會讓他優先完成一些特性。
    • 工程師獨立完成所有的特性——前端/後端/數據庫,等等所有相關的部分。 如果需要得到設計人員的幫助,需要先讓設計人員對你的想法產生興趣。 其他如架構之類的也一樣。 但總體來說,工程師要獨立完成所有的任務。
  • 對於某個特性是否值得開發的爭論,通常是這麼解決的:花一個星期的時間完成他,並在小部分人群中(如1%)進行測試。
  • 工程師常常希望解決難題,這能獲得聲望和尊敬。 他們很難對前端項目或UI設計產生太大的興趣。 這跟其他公司可能正好相反。 在facebook,後端任務,比如新的feed算法,廣告投放算法,memcache優化等等,是工程師真正感興趣的。
  • 所有的代碼修改都要進行審核(通過一個或多個工程師),但News Feed是個例外,因為太重要了,Zuckerberg會親自review。
  • 所有的修改至少要被一個人審核,而且這個系統可以讓任何人很方便地審核其他人的代碼,即使你沒有邀請他
  • 工程師負責測試,代碼修復,和維護自己的項目。
  • 每個辦公室或通過VPN連接的員工會使用下一版的facebook,這個版本的facebook會經常更新,通常比公開的早1-12小時。 所有的員工被強烈建議提交bugs,而且通常會很快被修復。
  • 很奇怪只有很少的QA或自動測試——"大部分工程師都能寫出基本沒有bug的代碼,只是在其他公司他們不需要這麼做。如果有QA部門,他們只要把代碼寫完,扔給他們就行了"
  • [針對上一條]我們有自動測試,代碼發布前必須要通過測試。 我們不相信"所有的工程師都能寫出沒有bug的代碼",畢竟這是一個商業公司。
  • 很奇怪,缺少產品經理的影響和控制——產品經理是很獨立的和自由的。 產生影響力的關鍵是與工程師和工程師的領導們搞好關係。 需要大致了解技術,不要提一些愚蠢的想法。
  • 所有提交的代碼每週二打包一次。
  • 只要多一分努力,總有一天會發生改變。
  • 星期二的代碼發布,需要所有的提交過代碼的工程師在場。
  • 代碼打包前,工程師必須在一個特殊的IRC channel上。
  • 運維執行打包過程
    • facebook有大約60000台服務器。
    • 有9個代碼發布級別。
    • 最小的級別只有6台服務器。
    • 星期二的代碼發布會先發佈到6台服務器上,運維組會檢測這6台服務器的反應,保證代碼正常工作,然後再提交到下一級。
    • 如果發佈出現了一些問題(如報錯等等),那麼就停止下一級的部署,提交出錯代碼的工程師負責修復問題,然後從頭繼續發布。
    • 所以一次發布可能會經歷幾次重複:1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6- 7-8-9。
  • 運維組是受過嚴格訓練,倍受尊敬,而且有商業意識的。 他們的工作包括分析錯誤日誌,負載和內存狀態等等,還包括用戶行為。
  • 代碼發布期間,運維組使用IRC-based頁面系統,可以通過facebook/email/irc/im/sms ping每一個工程師,如果需要他們注意的話。 對運維組不做回應是一件很羞愧的事。
  • 代碼一旦發佈到第9級,並且穩定運行,就算發布成功了。
  • 如果一個特性沒有按時完成,也沒什麼大不了的,下次完成時一併發布即可。
  • 如果被svn-blamed,public shamed或工作經常疏忽就很可能被開除。 "這是一個高效的文化"。 不夠高效或者不夠聰明的員工會被剔除。 管理層會在6個月的時間裡觀察你表現,如果不合格,只能說再見。 每一級都是這個待遇,即使是C級別和VP級別,如果不夠高效,也會被開除。
  • 被責罵不會導致解僱。 我們特別尊重別人,原諒別人。 大部分高級工程師都或多或少犯過一些嚴重的錯誤,包括我。 但沒有人因此被解僱。
  • 我也沒有遇到過因為上面提到過的犯錯誤而被解僱。 有些人犯了錯,他們會非常努力地去修復,也讓其他人得到了學習。

廣告

无觅相关文章插件,快速提升流量

Please publish modules in offcanvas position.