作為一個伺服器開發人員，目前我在負責現場問題處理，但是處理的問題多了，有了一些自己的思考。在處理過的問題中，有很多問題是比較低階的問題，比如判斷沒有else處理，記憶體洩漏等，還有一些問題是現場出問題後日志資訊不夠，無法得到有效的定位問題資訊，當然還有一些其他問題。導致這些問題的原因有很多，或許是因為編碼者的能力不一，也可能是侷限於自己的主觀性，無法排除問題。

       作為一個伺服器開發人員，經常需要處理現場發現的問題，這些問題經常很難定位，但定位的多了就有了一些自己的思考。筆者發現其實有很多問題是比較低階的問題，比如判斷沒有else處理，記憶體洩漏等，還有一些問題是現場出問題後日志資訊不夠，無法得到有效的定位問題資訊導致最後無法定位，當然還有一些其他因素。導致這些問題的原因有很多，或許是因為編碼者的能力不一，也可能是侷限於開發者自己的主觀性，無法排除問題。但其實以上問題其實可以通過程式碼編寫結束後的程式碼review進行有效排除。

       筆者在網上找了一些關於程式碼review的資料，發現自己對一下兩點有誤解：

• Code review不應該承擔發現程式碼錯誤的職責

Code Review主要是稽核程式碼的質量，如可讀性，可維護性，以及程式的邏輯和對需求和設計的實現。程式碼Bug應該由各種測試去保證。

• Code Review不應該成為保證程式碼風格和編碼標準的手段

程式設計師在提交程式碼Code Review時應該保證自己的程式碼是符合程式設計標準的，如果只是一味的去稽核程式碼的風格，對於大家的時間是浪費。

      Code Review清單

• 設計常規項

1. 遇到分支處理的時候是否考慮閉環全面考慮
2. 擴充套件性是否考慮
3. 是否存在安全漏洞

• 編碼常規項

1. 程式碼是否記憶體洩漏，是否效能低下，是否會形成crash
2. 各種異常邏輯是否處理
3. 程式碼能夠工作麼？它有沒有實現預期的功能，邏輯是否正確等
4. 所有的程式碼是否簡單易懂？
5. 程式碼符合你所遵循的程式設計規範麼？這通常包括大括號的位置，變數名和函式名，行的長度，縮排，格式和註釋
6. 是否存在多餘的或是重複的程式碼
7. 程式碼是否儘可能的模組化了
8. 是否有可以被替換的全域性變數
9. 是否有被註釋掉的程式碼
10. 迴圈是否設定了長度和正確的終止條件
11. 是否有可以被庫函式替代的程式碼
12. 是否有可以刪除的日誌或除錯程式碼

• 安全

1. 是否有註釋，並且描述了程式碼的意圖
2. 所有的函式都有註釋嗎
3. 對非常規行為和邊界情況處理是否有描述
4. 第三方庫的使用和函式是否有文件
5. 資料結構和計量單位是否進行了解釋
6. 是否有未完成的程式碼？如果是的話，是不是應該移除，或者用合適的標記進行標記比如‘TODO’

• 測試

1. 程式碼是否可以測試？比如，不要新增太多的或是隱藏的依賴關係，不能夠初始化物件，測試框架可以使用方法等
2. 是否存在測試，它們是否可以被理解？比如，至少達到你滿意的程式碼覆蓋(code coverage)
3. 單元測試是否真正的測試了程式碼是否可以完成預期的功能
4. 是否檢查了陣列的“越界“錯誤
5. 是否有可以被已經存在的API所替代的測試程式碼

• 經驗

1. 日誌是否可以將必要的資訊打印出來
2. 日誌是否可以得反映程式碼分支的走向
3. 結構體是否位元組對其
4. 使用被初始化為NULL的變數之前是否判空