從事技術(shù)開發(fā)的人員，對別人來走查代碼可以說是很排斥的，我就是其中之一，代碼寫的如何跟當(dāng)時的背景有關(guān)系，有時很急，有時需求就是不清不楚，反反復(fù)復(fù)變更等。

然代碼走查是真有必要，不管是新開發(fā)模塊還是維護變更，不管是大模塊還是只改一行代碼，都要去走查。

我遇到過一個很小很小的變更，就是加了個條件，結(jié)果當(dāng)時的開發(fā)人員自測場景寫的不全，更新生產(chǎn)后出現(xiàn)了嚴重的生產(chǎn)事故。

再者還有一種經(jīng)歷，在排查故障時，發(fā)現(xiàn)一行代碼不知道為啥變更，查找變更記錄無原因，當(dāng)事人已經(jīng)離職，怎么辦？只能全部捋一遍，代價之大。

可以說代碼變更引發(fā)的慘案代價是無法形容的，所以代碼走查要認真對待，不要走過過場，玩形式主義。

這邊分享下常見的需要改進地方:

注釋，真的很重要，但最容易被忽視的點，尤其是變更來源，變更原因

空指針，真的很重要，簡單，但也是被開發(fā)人員想當(dāng)然以為不會出現(xiàn)，而未加判斷

異常捕獲，很重要，務(wù)必記錄到日志文件，關(guān)鍵時刻，可是救命的藥，

數(shù)組越界，經(jīng)常出現(xiàn)數(shù)組未判斷大小，就直接用

分頁求總數(shù)，直接先獲取結(jié)果集，然后求結(jié)果集大小，內(nèi)存溢出，畢業(yè)生最容易犯這個錯誤

資源未釋放，比如數(shù)據(jù)庫資源，文件io資源，未及時釋放，運行一段時間，會來一份大禮資源不足的底層錯誤，畢業(yè)生常犯這樣的錯誤

查詢數(shù)據(jù)時，語句沒有參數(shù)控制，出現(xiàn)全表返回，乖乖內(nèi)存溢出。

sql注入，拼接語句查詢，職場新人常犯的錯誤

超時時間默認值，習(xí)慣了百度，直接粘貼過來，未設(shè)置連接超時，讀取超時，結(jié)果對方出問題時，自身系統(tǒng)受牽連