本文由程式設計師新視界原創翻譯，原文作者：Graham King，英文連結：https://www.darkcoding.net/software/facebooks-code-quality-problem/
Facebook已經在為他們一意孤行忽略代碼質量而自食其果。
Facebook有軟體質量問題。我會從三個方面來說明。之所以重要，是因為它展現的都是歷時彌堅的質量問題。至於如何展示，正如Facebook的工程師說的那樣，要規模化。最後，我還要說明一點，我沒有在Facebook工作過，也不是其競爭對手派來的，我只是一個旁觀者。
A：「iOS無法處理當今的規模」
大約一個月前，Facebook的工程師給出了一個報告：《iOS at Facebook》，之後在Reddit上引發了一場激烈的討論。
Facebook的iOS應用已超過18,000 Objective-C類，而且每一周就有429人為此作貢獻。在某種程度上，這429人是在為Facebook的iOS應用工作。不過，Facebook非但沒有吸取在ios應用上花太多人力物力的教訓，反而在報告中責怪git和xcode上那18000個類。
Reddit上來自於ChadBan的評論如此總結道：
這讓我想起了Martin Fowler的《Design Stamina Hypothesis》中關於沒有架構，系統會發生了什麼的描述。相較於那些完善的系統架構，這種殘缺的系統添加新功能更困難，所需要花費的時間也更長。至於解決方案，Facebook似乎只是選擇投入更多的開發者。我從不讓我的小團隊中的任何人認為這是時尚年輕人應該做的事情。我也從未想過以這種方式工作，雖然看上去這方法還挺適合Facebook的。
B：也許應該使用虛擬內存？
《Fast Database Restarts at Facebook》。第二個代碼質量問題來自於Facebook Research。從表面上看這是一篇蠻有趣的文章，當我看到這一處時，不由自主地繼續讀下去：
有一個重要發現是，我們可以將存儲生命周期從進程生命周期中分離開來。
這個想法類似於將數據存儲到memcached或redis中，重啟進程，讀回數據——可能你已經在這樣做了。唯一的區別是，你是將數據儲存在共享內存中，而不是在redis/ memcached中。共享內存實際上是個煙霧彈，直到文章的結論部分才承認這一點。
他們已經在重新啟動之間將數據持久化到磁碟了，但是從磁碟重新加載太慢了：「從磁碟讀取約120 GB的數據需要20-25分鐘；讀取磁碟格式的數據，並將其轉換成內存格式，需要2.5-3小時。」速度慢並不是因為磁碟，而在于格式轉換。最後他們終於意識到了這一點：「在磁碟恢復中一個很大的開銷就是將磁碟格式轉換為堆內存格式。我們計劃使用共享內存格式作為磁碟格式。」他們也寫了新的儲存/重載代碼，用一種新的格式轉換器來與共享內存合作。
如果你是Kerrisk的一個勤奮的讀者，那麼你會發現275頁（章節14.10）上的Linux共享內存是用一個tmpfs文件系統實現的。並且tmpfs就是Linux如何實現虛擬內存的，「消耗儘可能多的內存和交換空間，然後用於目前保存的文件」。
因此，如果你保存到磁碟的格式轉換程序讓你的代碼變慢了，因此不得不重寫這些代碼，並且想要「從進程生命周期中解耦存儲生命周期」，那麼你怎麼能不將你的磁碟文件寫到虛擬內存中呢？當然，他們也注意到了這一點，但已經為時已晚，因此他們不得不迅速採取行動並發布。
C：網站工作之時正是工程師度假的時候
《Fail at Scale》。Facebook承認他們有一個可靠性的問題，並且他們對此有一個專門的團隊。確定原因也很容易：
圖中的a表明發生在周六和周日的事件大大減少，儘管一周的網站流量保持在一個常量。圖中的b顯示在6個月的期限內，有且只有兩個星期，沒有事件發生：聖誕節的那一周，以及員工要為彼此之間寫同行評審的那一周。這兩個數據表明，當Facebook員工不積極更改基礎架構，忙於其他事情（周末，節假日，甚至是表現評估）時，網頁體驗的可靠性反而更高。
就是不知道定時發布會破壞app是不是軟體工程進程中的正常現象，你說呢？
結論
Facebook是相當成功的，顯然他們有一些偉大的工程師，資金也是源源不斷的，但是好像在軟體質量存在著大問題。我總結得到兩個經驗教訓：
文化問題。「黑客」和「快速前進打破常規」的文化使得開發人員很難專注於質量。質量問題。我們都知道，如果你不注重質量，那麼質量就會回過頭來咬死你。即使是做很小的變化也會變得越來越困難。Eric Evans在《Domain-Driven Design》寫道：「當複雜性失去控制，開發人員就不再能充分理解軟體來輕鬆和安全地改變或擴展它。」問題A就顯示了Facebook需要龐大的工作人員來維護敗絮其中的代碼以保持他們的勢頭。
發布將導致破壞，因為你不能充分理解關係，你做的改變會影響現有的代碼。問題C也說明了這一點。
下次當你再碰到有管理人員或客戶試圖說服你為了更快地前進，放棄質量的時候，當然你可以接受，因為這也能工作，只要你請得起429個工程師為我們的iOS app工作。