找 bug（如 testing）與去 bug（debugging），這在軟體工程裡是兩個截然不同的任務。發現 bugs，測試並非唯一手段，其他還有 code review、inspection 等等。
找 bugs 通常有幾個相對快速的辦法。
比如，為 code base 編寫/新增更多的自動單元測試，這是一種白盒測試。你 mentor 讓你「先從找 code base 中 bug 開始」，除了讓新手閱讀、熟悉老**外，大概也有這層意思。
找到 bugs 後，怎麼快速、高效地掐蟲（debugging）就是另一碼事了。
debug 對於新手來說普遍是一大弱項，在這上面常常要耗去大量的除錯時間。什麼原因？這主要是因為新手編碼、讀碼的量都很少，而且都沒經過什麼系統性的訓練，邏輯推理思維很弱，最關鍵一點是 —— 你們在大腦裡的思考，對於真實的軟體結構、軟體模型（尤其執行態模型）的理解是混亂的，所以往往很難像經驗豐富的老手那樣迅速、準確地定位 bug 所在。
0.優先解決那些可重現的
優先解決那些可重現的，可重現的bug特別好找，反覆除錯測試就好了，先把好解決的乾掉，這樣最節約時間。
1.抱同事的大腿
對於某些bug沒有頭緒或者現象古怪不知道從**下手，找有經驗的同事問一下思路，因為在那種開發多年的大型系統裡，經常會反覆出現同樣原因的bug，原因都類似，改了一處，過一陣子另外一處又冒出來，而且無法**。
比如：我那個系統裡有個特別危險的api，介面引數比較難用，一旦有人用錯了某些情況下就會出詭異的現象，解決很簡單，找到呼叫這個api的地方把呼叫方式寫對就好了。為什麼不**呢？因為要保持相容性不能改介面了。
問下老員工吧，說不定他們都遇到過好多次了。
放大現象
有些bug現象不太明顯，那麼就想辦法增大它的破壞性，把現象放大。這只是個思路，具體怎麼放大只能根據具體的**來定。
二分法定位
把程式邏輯一點點注釋掉，看看還會不會出問題，類似二分查詢的方法，逐步縮小問題範圍。
模擬現場
有時候我會問自己，如果我要實現bug描述的現象我要怎麼寫**才行？
比如：我遇到乙個死鎖問題，但是檢查**發現所有的鎖都是配對的，沒有忘記解鎖的地方，而且鎖很簡單就是乙個普通的臨界段，保護幾行賦值語句而已。這樣的**怎麼寫才能讓他死鎖呢？
我想如果讓我故意製造這樣乙個現象，只有在上鎖的時候強制殺掉執行緒了。
既然這樣就可以去看看有誰強殺執行緒了沒有。
製作工具
針對某些bug編寫一些除錯輔助工具。
比如，我那個系統沒有完善的崩潰報告，雖然也有dump，但是分析出來的callstack經常不准。於是我為解決崩潰問題編寫了個工具，會自動掃瞄**，在每個函式入口和出口插入log，以此來定位崩潰點。
掩蓋問題
雖然這樣做有點不厚道，但是有時不得不這麼做。有些bug找不到真正的root cause，但是又要在規定時間內解決，那麼我們就可以**症狀而不去找**。比如用try catch掩蓋一些奇怪的崩潰。不到萬不得已不要這麼幹，未來可能會付出更大代價。
結語debug的經驗本身就需要慢慢積累，所以新手要腳踏實地端正態度，及時發現問題並虛心接受和改進，達到目標並非遙不可及。因為寫程式可能靠天賦，debug不僅能讓你鍛鍊細心和耐心，還能讓你了解開發**現的各種問題，甚至在與開發人員的溝通中慢慢積累解決方式，這對於你以後寫**是非常大的幫助！
程式設計師如何減少BUG
最近乙個專案出了大量的bug，很是慚愧，有沒有可以盡量規避bug的良方呢？可能沒有，但總有儘量減少bug出現機率的方 吧 我個人覺得在企業應用開發中，bug大致可以分為如下三類 一 程式本身語義上的bug。執行時bug。比如np之類的。二 需求理解方面的差異導致的bug。簡單說，就是程式本身語義沒有...
程式設計師如何描述清楚線上bug
乙個管理後台的bug，把操作記錄中的操作員姓名，寫成了該操作員的id。原因是修改了乙個返回操作人姓名的函式，返回了操作人的id。但是還有其他地方也用這個函式，導致其他地方把姓名字段填寫成了操作員的id。該bug汙染了一條修改記錄，操作員手動刪除就好了。回滾 後恢復。本質是修改了函式的返回值，卻沒有檢...
程式設計師如何描述清楚線上bug
乙個管理後台的bug，把操作記錄中的操作員姓名，寫成了該操作員的id。原因是修改了乙個返回操作人姓名的函式，返回了操作人的id。但是還有其他地方也用這個函式，導致其他地方把姓名字段填寫成了操作員的id。該bug汙染了一條修改記錄，操作員手動刪除就好了。回滾 後恢復。本質是修改了函式的返回值，卻沒有檢...