崔雨鍇
這個問題對專業的來說是常識，不過我還是簡單解釋一下給外行看吧。權當娛樂。
找Bug這事，最簡單就是用開發工具，在代碼執行的時候設置斷點，看每條代碼執行之後的結果是否符合預期。程序員也會在一些地方把軟件的狀態記錄在日誌文件裡，就像飛機的黑盒子那樣的，當程序出現問題的時候反查日誌，也會對找到問題有幫助。
這些都是小兒科，但程序員幾乎每天都在做這些。
對於像Facebook這種大型軟件公司，如果光指望程序員這樣幹，那就不要玩了，有一套系統性的方法，叫做軟件工程，專門研究的是如何科學地管理軟件開發的過程。還有一系列質量認證來評估組織的過程管理能力，比如SEI-CMMI，類似工廠常用的ISO 9000系列，很多政府組織都要求有相關的資質才能接他們的項目。這裡就不展開了。
對創業公司而言，完全實施這種嚴謹的軟件過程成本很高。沒有50人以上，組織角色都湊不齊，不太現實。但是一般而言，每日構建還是最基本的開發實踐。
首先，所有代碼要有相關的測試代碼。比如，一個計算加法的程序，要有另一套程序負責測試其結果是否正確，用多種設計好的邊界數據進行檢驗。當然做加法的代碼不值得這樣，僅為舉例，不過大公司的測試程序數量遠遠大於正常的功能代碼，也要經過嚴格的同行評審才能提交入庫。
其次，比如微軟是每天五點之前每個人上傳當天改過的程序，系統編譯過後自動執行所有測試程序，保證所有人改過的集成之後，各種功能可以正常工作。這個測試會包含功能、性能及各種極端用例，通常會持續數個小時。軟件人員最怕就是下班了接到自己的代碼測試出錯的信息，那就意味著當天要改完通過測試，不然代碼庫會回滾到一天前，當日所有人的工作無進展。
儘管如此，總有一些問題會在上線後發生。畢竟各種硬件設備和運行環境的組合是個天文數字，手工找Bug還是免不了。這時候就看經驗了，高手的效率也許是生手的上百倍。所以很多軟件公司的高管都是技術出身，否則做個睜眼瞎，不知道會多花多少冤枉錢。
冬河草
我在通信研發幹過，做的是核心網設備操作系統中某個模塊的開發，整個公司的通信設備軟件代碼量加起來驚人，不亞於任何大型的軟件公司，那麼我們怎麼能快速定位到缺陷呢？
首先軟件代碼不可能一大坨，而是遵從自上而下的劃分原則有效的模塊化的。以前東家為例，那時候我們首先分設備（基站、接入網還是核心網），在設備上又分大的功能域Domain，在每個領域下又分若干個軟件模塊（我們稱為programblock或簡稱PRB）。每個軟件模塊可以看做是可以獨立運行的程序，與其它模塊通過協議接口交互。於是每個開發團隊會負責若干個軟件模塊的開發測試及維護。我們的代碼庫裡可以看到上千個軟件模塊，各自還有若干的版本和分支，其複雜度可想而知。
為便於維護和缺陷定位，我們都有嚴格的日誌規範與標準，在不同的異常情況下要寫不同等級的日誌，如警告、嚴重及致命等。這樣前方技術支持在發生問題的時候可以通過抓取日誌來分析哪些軟件模塊報了什麼樣的問題，尤其關注那些等級高的日誌。後端的研發人員通過查看日誌及相關參數記錄，就能快速定位到某個具體模塊的代碼位置。
另外，開發團隊還要承擔本地的測試工作，一直管到功能測試為止，即單元測試、功能測試還有迴歸測試。在這之上，團隊的測試專家還要配合系統測試團隊寫集成測試以及性能測試用例。這有利於團隊熟悉自己代碼所對應的應用場景，並且通過迴歸測試來保證新的開發不破壞老的功能。
最後就是有效的代碼庫管理。我們那時候用的是SVN，但代碼合併不是隨意的，有專人負責，有測試用例保護，還需要經過代碼審查。未審查過的代碼嚴禁提交合並，測試用例沒跑過的也不許提交。本地提交改動前還要遵循規範操作，比如必須先將代碼拉取到本地，有衝突的本地解決才能提交，以避免代碼衝突和缺失等。
綜上所述，對產品進行模塊化分工、嚴格的代碼管理、充分的測試還有有效的日誌工具，都是工程師能快速定位大型軟件代碼缺陷的有效手段。
江南漁夫
在臉書如何找bug沒有開發新功能重要。絕大部分工程師工作的目標都是為了performance好看。修bug並不會對performance有多大作用，除非是修別人造成的sev級別bug。所以很多時候就算髮現了bug也不會管，而是專心完成手頭項目。
Ca2019
單元測試，模擬測試，跟蹤流程就這麼找bug，就目前我是這麼做的！
說的不多_多的不說
題主您好。
在開發的時候，無論是什麼語言，我們都會使用一個工具，叫做 “日誌”，我們會在自己的代碼中加入各種各樣的日誌，從而輔助判斷檢測問題的所在之處。
此外，我們還可以藉助一些Debug工具，來輔助進行錯誤的定位。
