我在通訊研發幹過，做的是核心網裝置作業系統中某個模組的開發，整個公司的通訊裝置軟體程式碼量加起來驚人，不亞於任何大型的軟體公司，那麼我們怎麼能快速定位到缺陷呢？

首先軟體程式碼不可能一大坨，而是遵從自上而下的劃分原則有效的模組化的。以前東家為例，那時候我們首先分裝置（基站、接入網還是核心網），在裝置上又分大的功能域Domain，在每個領域下又分若干個軟體模組（我們稱為programblock或簡稱PRB）。每個軟體模組可以看做是可以獨立執行的程式，與其它模組透過協議介面互動。於是每個開發團隊會負責若干個軟體模組的開發測試及維護。我們的程式碼庫裡可以看到上千個軟體模組，各自還有若干的版本和分支，其複雜度可想而知。

為便於維護和缺陷定位，我們都有嚴格的日誌規範與標準，在不同的異常情況下要寫不同等級的日誌，如警告、嚴重及致命等。這樣前方技術支援在發生問題的時候可以透過抓取日誌來分析哪些軟體模組報了什麼樣的問題，尤其關注那些等級高的日誌。後端的研發人員透過檢視日誌及相關引數記錄，就能快速定位到某個具體模組的程式碼位置。

另外，開發團隊還要承擔本地的測試工作，一直管到功能測試為止，即單元測試、功能測試還有迴歸測試。在這之上，團隊的測試專家還要配合系統測試團隊寫整合測試以及效能測試用例。這有利於團隊熟悉自己程式碼所對應的應用場景，並且透過迴歸測試來保證新的開發不破壞老的功能。

最後就是有效的程式碼庫管理。我們那時候用的是SVN，但程式碼合併不是隨意的，有專人負責，有測試用例保護，還需要經過程式碼審查。未審查過的程式碼嚴禁提交合並，測試用例沒跑過的也不許提交。本地提交改動前還要遵循規範操作，比如必須先將程式碼拉取到本地，有衝突的本地解決才能提交，以避免程式碼衝突和缺失等。

綜上所述，對產品進行模組化分工、嚴格的程式碼管理、充分的測試還有有效的日誌工具，都是工程師能快速定位大型軟體程式碼缺陷的有效手段。

在開發的時候，無論是什麼語言，我們都會使用一個工具，叫做 “日誌”，我們會在自己的程式碼中加入各種各樣的日誌，從而輔助判斷檢測問題的所在之處。

此外，我們還可以藉助一些Debug工具，來輔助進行錯誤的定位。

這個問題對專業的來說是常識，不過我還是簡單解釋一下給外行看吧。權當娛樂。

找Bug這事，最簡單就是用開發工具，在程式碼執行的時候設定斷點，看每條程式碼執行之後的結果是否符合預期。程式設計師也會在一些地方把軟體的狀態記錄在日誌檔案裡，就像飛機的黑盒子那樣的，當程式出現問題的時候反查日誌，也會對找到問題有幫助。

這些都是小兒科，但程式設計師幾乎每天都在做這些。

對於像Facebook這種大型軟體公司，如果光指望程式設計師這樣幹，那就不要玩了，有一套系統性的方法，叫做軟體工程，專門研究的是如何科學地管理軟體開發的過程。還有一系列質量認證來評估組織的過程管理能力，比如SEI-CMMI，類似工廠常用的ISO 9000系列，很多政府組織都要求有相關的資質才能接他們的專案。這裡就不展開了。

對創業公司而言，完全實施這種嚴謹的軟體過程成本很高。沒有50人以上，組織角色都湊不齊，不太現實。但是一般而言，每日構建還是最基本的開發實踐。

首先，所有程式碼要有相關的測試程式碼。比如，一個計算加法的程式，要有另一套程式負責測試其結果是否正確，用多種設計好的邊界資料進行檢驗。當然做加法的程式碼不值得這樣，僅為舉例，不過大公司的測試程式數量遠遠大於正常的功能程式碼，也要經過嚴格的同行評審才能提交入庫。

其次，比如微軟是每天五點之前每個人上傳當天改過的程式，系統編譯過後自動執行所有測試程式，保證所有人改過的整合之後，各種功能可以正常工作。這個測試會包含功能、效能及各種極端用例，通常會持續數個小時。軟體人員最怕就是下班了接到自己的程式碼測試出錯的資訊，那就意味著當天要改完透過測試，不然程式碼庫會回滾到一天前，當日所有人的工作無進展。

儘管如此，總有一些問題會在上線後發生。畢竟各種硬體裝置和執行環境的組合是個天文數字，手工找Bug還是免不了。這時候就看經驗了，高手的效率也許是生手的上百倍。所以很多軟體公司的高管都是技術出身，否則做個睜眼瞎，不知道會多花多少冤枉錢。

在臉書如何找bug沒有開發新功能重要。絕大部分工程師工作的目標都是為了performance好看。修bug並不會對performance有多大作用，除非是修別人造成的sev級別bug。所以很多時候就算髮現了bug也不會管，而是專心完成手頭專案。