程序調試技巧

　　這篇博文一看就知道是老手寫出來的，可以讀懂其中的味道，說明也不簡單，https://blog.codingnow.com/2018/05/ineffective_debugger.html

　　目前在公司的工做，主要就是修代碼，調bug，因此在調試代碼方面仍是應該多留意的。今天leader說一個專業名詞：單步調試，我一臉懵逼，這樣的工做我也作過啊，也是一步步看變量狀態，只是作的不夠專業罷了，其餘的方法如2盯着代碼看（code review），3查看輸出日誌（最原始的大法就是system.out大法，4使用swagger，postman等。

　　接下來就是要注意調試的環境問題。有的程序是一鍵部署到服務器上面的。若是咱們的程序還調用了其餘服務，則須要確保相關的配置文件正確。最方便的狀況就是在本地調試了，這樣能實時看日誌。今天老大就給我示範了兩個調bug的經典例子，一個是看log日誌文件，在日誌文件看到了拋出異常，再回看代碼，咱們的代碼沒有對這類異常進行捕捉，因此業務就出現異常。還有就是在本地經過單步調試發現咱們的swagger輸出沒有問題，而是相關服務調用個人服務出錯，這是從咱們服務的服務輸出推斷的。

　　其中在log調試時，向同事問了幾個linux命令，挺實用的，好比tail -f file.out:會實時跟蹤輸出。sed -i '1,100d' file.out：刪除文件的指定行，不然不少日誌不知道怎麼看。暴力刪除文件：find / -name *.log | xargs rm -f

　　而後就是修改代碼的時候，要習慣使用idea中的交戶界面操做，這樣雖然不及命令行快捷方便，可是命令行輸出獲得的東西咱們看起來也不方便。在查看文件的diff命令很直觀，還有就是咱們能夠只提交某個文件的更改，定位相應的文件也很塊。還有就是用戶的每次提交都會使遠程的文件版本向前，在多人協做時，若是你的版本落後於遠程版本，就會push失敗（這是常常出現的狀況），因此要注意先pull一下。