代碼自查的總結

很多人代碼一些完，馬上開始Make, 殊不知他錯過了一次很好的機會。這個機會就是代碼自查，它的目的不僅僅是為了發現程序的錯誤，更是為了認識到自己編程習慣的局限和盲點，從而在下次進行有效地改進。因為，人自己發現自己的錯誤并修改的過程，是一種自愈和自我免疫的過程。

1. 前提

滿足了下面的前提，就可以開始代碼自查：

• 項目需求已經確定，有可參考和檢查的文檔，
• 主要的功能，已經拆分為各個子模塊；
• 和其他模塊的接口，已經定義好；
• 每個模塊的代碼，已經用代碼實現；

當然，如果你模塊劃分得越細，也可以逐模塊開始代碼自查。

2. 過程

可以做兩輪自己的code review，每輪的側重點不一樣：

2.1 功能自查

第一輪檢查，主要側重于以下的方面的檢查

2.1.1 文件級

重點檢查：

• 頭文件是否能避免重復保護；
• 如果需要支持C++，頭文件是保護extern C；
• 頭文件中的extern 是否有定義；
• 頭文件中的函數是否有定義、定義是否一致；
• 是否遵循最小暴露原則；
• 在全局靜態數組的定義中，使用了需要運行時才能確定的變量，導致了編譯錯誤

2.1.2 子模塊級

• 子模塊內部實現的邏輯是否符合預期；
• 子模塊對外的接口函數的參數和返回值是否恰當；
• 是否有之和子模塊相關的變量實現成了全局變量；

2.1.2 函數級

• 輸入輸出參數是否冗余、缺失、類型不對；
• 函數內部是否聲明了不用的變量；
• 函數返回和函數聲明是否一致；
• 參數檢查是否遺漏或者過多；
• 內部循環是否退出條件過若或者過強；
• swtich/case 是否遺漏break、default,或者default不可能執行到
• 申請的內存是否遺漏釋放；
• 對申請到的內存的使用是否越界；
• 該函數是否在臨界區，是否包含臨界區，是否會死鎖；
• 功能邏輯是否符合預期

2.1.3 宏定義級

• 是否有些近似的代碼反復出現沒有用宏替換
• 是否把宏當做函數用了，忽略了宏定義只是簡單的完全替換關系

2.1.4 拼寫級

• 有一個數據結構中的一個成員，只有類型，沒有變量名稱；
• 遺漏分號、過多分號；
• 拼寫錯誤，特別是夾雜有大小寫的情況：idLsu/idlsu lsfsret/LsfsRet

上面檢查過程中，發現立即可以修改的馬上修改，比較復雜的可以放到一個TODO list的FIFO里去；

2.2 性能檢查

第二輪檢查側重于以下的方面：

2.2.0 算法

針對具體的功能和場景，區分是響應時間有限還是節省資源有限，列出所有可選的算法實現，確定是否當前是最合適的實現；

2.2.1 IO路徑

• IO路徑上的所有操作是否都是必需在請求返回前執行的，如果不是，可以拆分到后臺線程去執行；
• IO路徑上是否會全搶鎖等待，如果有盡量去掉鎖或者減小等待的時機；

2.2.2 并發的粒度

• 是用多進程還是多線程去并行；
• 是否需要綁定處理器核去執行；

2.2.3 鎖的類型

• 是否必需，能否用無鎖隊列替換；
• 是否適用讀寫鎖；

2.2.4 IO合并和放大

• 每次是否有太多的沒有改動的數據也落盤了；
• 是否依賴了必需落盤的數據，導致它沒及時落盤；

同樣，如果上面有問題，也需要添加到一個TODO List里面去。

2.3 完成TODO List

• 根據上面自查完成后生產的TODO list，把里面每一項完成；
• 完成TODO list后，對照自己常犯錯誤的清單，再次自查，修改完成之后可以交由編譯器去編譯調試了。

如果此時，你發現編譯器也沒發現任何錯誤和警告，恭喜你，已經比較牛了！

轉載于:https://blog.51cto.com/xiamachao/2054948

總結

以上是生活随笔為你收集整理的代码自查的总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。