平常心看「Facebook如何管理程式碼」

上個月國外流傳著一篇「How Facebook Ships Code」，描述Facebook內部如何管理程式碼，把Facebook描述成軟體工程師的天堂。文章傳來傳去，不但有了簡體中文翻譯版，最近連我的一些朋友的mailing list都在傳。基本上我是很願意相信Facebook有著良好的程式管理制度，但是這篇文章的內容實在也太神奇了。這兩天本來想要戳一下這篇，沒想到翻翻原文，底下的討論區早已經有許多人〈包括Facebook的工程師〉也提出質疑，到最後原文作者也修改了不少內容。也罷，那麼今天這個就來看這篇文章到底有哪些問題。

原圖：Flickr

還沒看過原文的，建議可以直接看簡中翻譯：

facebook是如何管理代碼的

那麼，以下就是我個人逐字對這篇文章所提出的看法：

• 我對facebook的運作著迷。這是一個非常獨特的環境，不容易被複製（他們的體系並不適合所有的公司，即使他們努力嘗試過）。下面是我和facebook的朋友們關於他們如何開發和管理專案的記錄。

開宗明義就告訴你「我不是Faceook工程師，這是我問我朋友的」！文章可信度先打三折。

• 每個工程師入職時，都要接受4-6周的培訓，修bug、上資深工程師的課程，熟悉facebook。
• 培訓結束後，每個工程師都可以接觸線上的資料庫(更大的權力意味著更大的責任，也有一份”勿做清單”，不然可能會被開除，比如共用用戶的隱私資料)。

可惜Zynga〈還有那些賣人頭帳戶的〉沒有上過這些課。

• 每個工程師可以修改facebook的所有程式碼，隨時可以check in。
• 有非常牢靠的安全體系，以免有人不小心/故意做了些不好的事。
• 所有的代碼修改都要進行審核(通過一個或多個工程師)，但News Feed是個例外，因為太重要了，Zuckerberg會親自review。

一開始看到「任何人都可以修改Facebook所有程式碼」，有點嚇到；看到後來，想想也許並沒那麼誇張；你可以自由check in任何程式碼，但是程式碼如果沒經過任何人code review就無法deploy。這麼說來其實也還好。

• 完全沒有QA〈原文是：no QA at all, zero〉。工程師負責測試，代碼修復，和維護自己的專案。
• 很奇怪，只有很少的QA或自動測試——”大部分的facebook工程師都能寫出沒有bug的程式碼，只是在其他公司他們不需要這麼做。如果有QA部門，他們只要把程式碼寫完，扔給QE就行了”

這簡直是胡扯。2000多個工程師寫出來的程式碼都沒有bug？打死我都不信。果然原文後面多了好多讀者的更正：

[CORRECTION thx fryfrog] “I would also add that we do have QA, just not an official QA group. Every employee at an office or connected via VPN is using a version of the site that includes all the changes that are next in line to go out. This version is updated frequently and is usually 1-12 hours ahead of what the world sees. All employees are strongly encouraged to report any bugs they see and these are very quickly actioned upon.”

〈我必須要說我們有QA啦，只是不是正式的獨立團隊。每個員工都可以透過VPN連到最新版的Facebook網站。這個站每1~12小時更新一次，公司鼓勵全部工程師都在上面玩、並隨時回報bug〉

[CORRECTION thx epriest] “We have automated testing, including “push-blocking” tests which must pass before the release goes out. We absolutely do not believe “most engineers are capable of writing bug-free code”, much less that this is a reasonable notion to base a business upon.”

〈我們也有自動測試啦，有的測試如果沒過，新版是不能釋出的；我們絕對不會說所有的工程師都能寫出無bug的程式碼。〉

[EDIT: please note that this was subjective opinion, I chose to include it in this post because of the stark contrast that this draws with standard development practice at other companies]

〈作者更正：抱歉這只是我個人的主觀意見啦，我會這樣說是因為Facebook的工作環境太獨特了〉

不回頭看原文，還真差點被呼攏過去。真的的情況應該是，很少有誰專職作QA，因為公司鼓勵全民都可以當QA。

不過全民作QA的一個壞處就是，如果誰不小心搞出一段很明顯的bug，那麼大概一次會收到幾十個bug、都在講同一個bug，溝通成本應該會很高吧。

• 如果工程師搞爛svn、常被當眾責罵或工作經常疏忽。就很可能被開除。”這是一個追求高效率的文化”。不夠高效或者不夠聰明的員工會被剔除。管理層會在6個月的時間裡觀察你表現，如果不合格，只能說再見。每一職等都是這個待遇，即使是C職等或VP〈Vice President〉，如果效率不夠，也會被開除。

這太誇張了，這不只是追求效率，而是追求壓力的環境吧？

文章底下又有讀者更正：

[CORRECTION, thx epriest]  “People do not get called out for introducing bugs. They only get called out if they ask for changes to go out with the release but aren’t around to support them in case something goes wrong (and haven’t found someone to cover for you).”

〈工程師不會因為常寫出bug就被fire，只有那些常寫出一堆bug、出問題時不在場、又找不到人幫忙修的人，才會被開除〉

[CORRECTION, thx epriest] “Getting blamed will NOT get you fired. We are extremely forgiving in this respect, and most of the senior engineers have pushed at least one horrible thing, myself included. As far as I know, no one has ever been fired for making mistakes of this nature.”

〈被罵不會害你被fire啦，誰沒寫出bug過？〉

[CORRECTION, thx fryfrog] “I also don’t know of anyone who has been fired for making mistakes like are mentioned in the article. I know of people who have inadvertently taken down the site. They work hard to fix what ever caused the problem and everyone learns from it. The public shaming is far more effective than fear of being fired, in my opinion.”

〈我從沒聽過誰因為上述原因而被fire的。我還知道有人不小心讓全站都掛掉。當下這些人都在很努力的修bug，而全公司的人也都從中上了一課。比起被fire，怕當眾丟臉的壓力還比較大〈也比較有效〉呢。〉

• 以工程師為導向的文化。一名Facebook員工曾說：「產品經理〈PM〉基本上可以被忽略」。工程師可以修改流程的細節，重新安排工作任務，隨時提出自己的想法。
• 每月的跨部門會議，是由工程師來彙報工作進度。市場部和產品經理會出席會議，也可以做些簡短的發言，但如果說得太多，很可能就會被打小報告。他們真的想讓工程師來主導產品的開發，對自己的產品負責。

好吧，重頭戲來了，PM的角色到底重不重要？我想這見仁見智，有時候大家遇到狀況外的PM，都會很想砍人，罵說”我自己來做都比他好”，只是PM這個角色可以這麼輕易的被忽略嗎？一個好的PM，要時時注意市場脈動，即時做出反應與決策。Facebook竟然沒有PM？

[EDITORIAL] The author of this blog post is a product manager, so this sentiment really caught my attention.  As you’ll see in the rest of these notes, though, it’s apparent that Facebook’s culture has really embraced product management practices so it’s not as though the role of product management is somehow ignored or omitted.  Rather, the culture of the company seems to be set so that *everyone* feels responsibility for the product.

“原文更正啟事：抱歉，本文作者自己是PM，所以這整段（PM不重要）都是作者自己的感言。這段的原意是，產品管理的精神已經置入了整個Facebook的文化，所以並不是說不需要PM這個角色，而是人人皆PM的意思”

所以是說以上全篇針對Facebook開發環境多好多好的感想文，全都不是軟體工程師自己寫的，而是一位不在Facebook工作的PM從旁觀察的心得（註：原作者在Skype當PM）？

難怪這篇文章後來勘誤這麼多啊…（Quora上也有不少人提出更正）

不過話說回來，原文推出後，修修改改這麼多，當中有幾段是沒被修改過的，顯然這才是真正值得觀察的：

專案的參與人員都是自願的

• 一個PM（！）召集工程師們，讓他們對新專案產生興趣
• 工程師們決定要開發哪些他們感興趣的功能。
• 工程師跟老闆說：下個月我想參與開發這五個功能。
• 老闆會讓工程師參與，但有時某些功能會優先做。
• 工程師獨立完成所有的功能——Front End/Back End/資料庫等等所有的部分。如果需要美工人員幫忙，也需要先讓美工對你的想法有興趣，架構之類的問題也一樣。總體來說，工程師要獨立解決所有問題。

所以整體來說，就是”讓你的工程師對他所正在做的產品感興趣、讓他參與整個開發的決策流程”，而不是把工程師視為”一群負責寫程式的僕人”。

這不知道已經聽過多少次了，但是對應到實際的開發上，還是很困難。或許，Facebook本身就是社交網路應用，所以工程師相對容易把自己投射成使用者。換做是一些企業軟體的開發，恐怕就有點難度了。

過去的今天：

• 我看台灣博客 - 2008
• [客座] 消費者口碑影響力進入後期的期待與改變 - 2008
• 搬運機器人BigDog - 2007
• Microsoft Vista的反擊 - 2007
• R2D2垃圾桶 - 2007
• NASA會自我組裝的機器人 - 2007
• 連老人都玩Wii - 2007
• Microsoft被判支付天價賠償金 - 2007
• Google Apps的推出及其影響 - 2007

相關推薦

• memolane – 回憶過去一年的我 (2)
• Facebook + Bing + WP7 … 看臉書與微軟攜手合作的威力 (4)
• Facebook要進軍手機市場！？ (7)
• Bloglines 之死 (20)
• 你知道現在可以用BT下載一億個Facebook用戶帳號資料了嗎？ (17)

分享

文章標籤: Facebook, product management

文章分類: Business, Facebook, Mr. Friday, 專欄, 管理

via feedproxy.google.com