修改bug入手，通過一個個小bug去了解整個project的結構和design pattern，對新人來說，這種學習既直觀又不會被復雜的代碼嚇死，
幾個debug的經驗:
1. 優先解決那些可重現的，可重現的bug特別好找，反復除錯測驗就好了，先把好解決的干掉，這樣最節約時間，
2. 對于某些bug沒有頭緒或者現象古怪不知道從哪里下手，找有經驗的同事問一下思路，因為在那種開發多年的大型系統里，經常會反復出現同樣原因的bug，
原因都類似，改了一處，過一陣子另外一處又冒出來，而且無法根治，
比如：我那個系統里有個特別危險的API，介面引數比較難用，一旦有人用錯了某些情況下就會出詭異的現象，解決很簡單，找到呼叫這個API的地方把呼叫方式寫對就好了，
為什么不根治呢？因為要保持兼容性不能改介面了，Windows系統里就好多這種爛API，問下老員工吧，說不定他們都遇到過好多次了，
3. 放大現象，有些bug現象不太明顯，那么就想辦法增大它的破壞性，把現象放大，這只是個思路，具體怎么放大只能根據具體的代碼來定，
比如：美劇《豪斯醫生》里有一集，懷疑病人心肺有問題，就讓病人去跑步機上跑步，加重心肺負擔，從而放大癥狀，
4. 二分法定位，把程式邏輯一點點注釋掉，看看還會不會出問題，類似二分查找的方法，逐步縮小問題范圍，
5. 模擬現場，有時候問自己，如果我要實作bug描述的現象我要怎么寫代碼才行？比如：遇到一個死鎖問題，但是檢查代碼發現所有的鎖都是配對的，
沒有忘記解鎖的地方，而且鎖很簡單就是一個普通的臨界段，保護幾行賦值陳述句而已，
這樣的代碼怎么寫才能讓他死鎖呢？如果讓我故意制造這樣一個現象，只有在上鎖的時候強制殺掉執行緒了，既然這樣就可以去看看有誰強殺執行緒了沒有，
6. 制作工具，針對某些bug撰寫一些除錯輔助工具，比如，那個系統沒有完善的崩潰報告，雖然也有dump，但是分析出來的callstack經常不準，
于是為解決崩潰問題撰寫了個工具，會自動掃描代碼，在每個函式入口和出口插入log，以此來定位崩潰點，
7. 掩蓋問題，雖然這樣做有點不厚道，但是有時不得不這么做，有些bug找不到真正的root cause，但是又要在規定時間內解決，那么我們就可以治療癥狀而不去找病因，
比如用try catch掩蓋一些奇怪的崩潰，不到萬不得已不要這么干，未來可能會付出更大代價，
另外如果你想更好的提升你的編程能力，學好C語言C++編程！彎道超車，快人一步！筆者這里或許可以幫到你~
點擊此處免費分享（原始碼、專案實戰視頻、專案筆記，基礎入門教程）
歡迎轉行和學習編程的伙伴，利用更多的資料學習成長比自己琢磨更快哦！
編程學習：
編程學習：
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/275695.html
標籤：其他