寫代碼就難免有BUG，很多時候，BUG令人無從下手，似乎很鬼畜，似乎不符合語言、編譯器甚至是計算機的運行機理。但是往往最後我們發現，越是難以置信的BUG來源於更低級的錯誤與失誤。
（一）、更多時候，調BUG考驗我們的並非對於編程技術、對運行機理的理解或者別的技術相關的，而是我們的心態。
（二）、懷疑該懷疑的，堅信該堅信的。這需要我們做一個篩選，在所有的用到的代碼、庫和工具中，有一些需要我們堅信其是不可能出現錯誤或者BUG的，除非是我們忽略了它們定義的規則。而通常，我們至少要信任自己的編譯器。一旦確定了該被信任的工具，那麼在單步調試過所有代碼之前都不要在懷疑。這並不永遠是對的，但是這絕大多是時候是正確的。當我們過早的懷疑這些本該信任而又無法查看源碼乃至沒有過多說明資料的對象時，我們會發現我們的BUG永遠都不可能被調試出來了。我們推選出的該被懷疑的代碼裏面，我們應當遵從這樣的懷疑等級順序：自己寫的代碼>同事寫的代碼>免費的第三方庫>收費的商業性第三方庫。
（三）、大膽假設，細心驗證。這其實是一個很難的事情，至少對我本人而言，這和性格有關，但是我們應當經常提醒自己去做到。越是難以置信的BUG往往來源於更低級的更難以引起注意的一些小的細節上的失誤，比如>、<錯寫成<=、>=或者相反？索引從0開始還是從1開始？等等諸如此類。在該被懷疑的代碼裏面，放心大膽的去懷疑吧！然後仔細的調試、驗證你的懷疑。
（四）、更多的依賴官方資料。曾經有一位老師曾經告訴我：“如果這些設計者出具的資料都不可信，那麼世界上還有可信的資料嗎？”在你所能找到的所有的資料中，配套的官方文檔（如果有的話）是最值得信任的，它不帶有任何與編輯者知識、認知、經歷等任何相關的產物，只有最最直白只爲說明問題的文字。
（五）、合理斷點和Log。這是調試BUG最常用的方式了，但是似乎很難說清需要在什麼地方打Log或者斷點，也就是怎樣纔算合理。一般而言我認爲Log用來確定問題出現的位置，因爲運行時不需要回到源碼就可以查看想看到的關鍵值的狀態，而斷點則用來確定這些問題出現的原因,因爲當斷點觸發，代碼塊中所有值得狀態都能看到，整個執行過程能夠推演回去，而且調用堆棧（Call Stack）能夠回退到更早的代碼處，並且還原當時的值的狀態。