基本代碼檢查清單
我們來討論基本的代碼審查清單，這對于code review的新手非常有用.
1.自己是否可以很容易的理解代碼？
2.代碼是否遵循編碼規(guī)范？
3.相同的代碼是否重復(fù)兩次？
4.是否可以單元測試或者調(diào)試代碼，定位到問題的根本原因？
5.這個函數(shù)或類是否太大？如果是的，函數(shù)或類是否有太多的職責？
詳細代碼檢查清單
以下代碼審查清單提供了在審查代碼時需要考慮的各個方面
1.代碼格式化
在查看代碼時，檢查代碼格式以提高可讀性，確保沒有阻塞：
a）使用對齊（左邊距），正確的空格。還要確保代碼的開始和結(jié)束容易識別。
b）確保遵循正確的命名約定（Pascal，CamelCase等）。
c）代碼應(yīng)符合標準的14寸筆記本電腦屏幕。在21英寸顯示器中，不需要水平滾動來查看代碼，可以在修改代碼的同時打開其他窗口（工具箱，屬性等），因此確保代碼在14英寸顯示器正常。
d）刪除掉注釋的代碼。如果需要，可以從源代碼控制（如SVN）獲取到。
2.架構(gòu)
代碼應(yīng)遵循已經(jīng)定義好的架構(gòu)。
1.有關(guān)分層
根據(jù)需要進行分層（展現(xiàn)層，業(yè)務(wù)層和數(shù)據(jù)層)。
對文件類型進行劃分（HTML，JavaScript和CSS）。
2.代碼和現(xiàn)有的代碼規(guī)范/技術(shù)保持同步。
3.設(shè)計模式：在完全理解問題和業(yè)務(wù)之后，使用適當?shù)脑O(shè)計模式（如果可以）。
3.良好的編碼習慣
1.沒有硬編碼，使用常量/配置值。
2.一組相似的值使用枚舉（ENUM）。
3.注釋 - 不要為你正在做的事情寫注釋，而是寫出你為什么要這么做。指出使用 的技巧，解決方法和臨時修復(fù)。另外，在to-do注釋里寫上待處理的任務(wù)，可 ? ? 以方便跟蹤。
4.避免多個if/else塊。
5.盡可能使用框架提供的功能，而不是自己造輪子。
4.非功能要求
a）可維護性（可支持性） - 希望系統(tǒng)在未來花最少的精力去做維護。應(yīng)該容易定位和修復(fù)問題
1.可讀性：代碼應(yīng)該是清晰易讀的?？梢詮拇a中讀取很多信息，使用恰當?shù)淖兞棵瘮?shù)名，類名。如果你用很多的時間去閱讀代碼，說明代碼需要重構(gòu)或者至少要把注釋寫的清楚點。
2.可測試性：代碼應(yīng)該很容易被測試。拆分成一個單獨的函數(shù)（如果需要）。系統(tǒng)的其他層使用接口，可以很方便的mock。避免靜態(tài)函數(shù)，單例類，因為這些不容易被mock測試。
3.可調(diào)試性：可以打印日志，參數(shù)數(shù)據(jù)和異常詳細信息，可以方便定位到問題原因。如果你正在使用log4net的類似組件，可以添加支持數(shù)據(jù)庫日志，查詢?nèi)罩颈砗苋菀住?/p>
4.可配置性： 可配置的值放到以下地方（XML文件，數(shù)據(jù)庫表），數(shù)據(jù)可以自由變更不需要改代碼。
b）可重用性
1.DRY（Do not Repeat Yourself）原則：同一代碼不應(yīng)該重復(fù)兩次以上。
2.考慮可重用的服務(wù)，功能和組件。
3.考慮通用函數(shù)和類。
c）可靠性 - 異常處理和清理（釋放）資源。
d）可擴展性 - 輕松添加功能，對現(xiàn)有代碼進行最小的更改。一個組件可以被更好的組件替換。
e）安全性 - 進行身份驗證，授權(quán)，輸入數(shù)據(jù)驗證，避免諸如SQL注入和跨站腳本（XSS）等安全威脅 ，加密敏感數(shù)據(jù)（密碼，信用卡信息等）
f）性能
1.使用合適的數(shù)據(jù)類型，例如StringBuilder，通用集合類。
2.懶加載，異步和并行處理。
3.緩存和會話/應(yīng)用程序數(shù)據(jù)。
g）可擴展性 - 考慮是否支持大用戶量/大數(shù)據(jù)？是否可以部署到集群？
h）可用性 - 站在用戶的角度考慮下接口/API是否容易理解和使用，如果你不確定用戶接口的設(shè)計，可以和業(yè)務(wù)人員一起討論你的想法
5.面向?qū)ο蠓治雠c設(shè)計（OOAD）原則
單一責任原則（SRS）：不要將多個職責放在單個類或函數(shù)中，提取出單獨的類和函數(shù)。
開放封閉原則：添加新功能時，不應(yīng)修改現(xiàn)有代碼。 新功能應(yīng)該用新的類和函數(shù)來編寫。
Liskov替換原則：子類不應(yīng)改變父類的行為（含義）。子類可以用作基類的替代。
接口隔離：不要創(chuàng)建冗長的接口，而是根據(jù)功能將它們拆分成較小的接口。接口不應(yīng)包含功能不需要的依賴項（參數(shù)）。
依賴注入：針對依賴不要硬編碼，而是注入它們。
在大多數(shù)情況下，原則是相互關(guān)聯(lián)的，遵循一個原則也會滿足其他原則。如果遵循“單一責任原則”，則可重用性和可測試性將會加強。
在少數(shù)情況下，一個需求可能與其他需求相矛盾。因此，需要根據(jù)重要性進行權(quán)衡，例如。性能與安全性（UI，中間層，數(shù)據(jù)庫）的檢查和日志記錄太多會降低應(yīng)用程序的性能。但是有些系統(tǒng)，特別是與金融和銀行有關(guān)的應(yīng)用程序需要很多埋點，審核日志記錄等。因此，在性能方面有一點妥協(xié)可以增強的安全性。
代碼審查工具
1.評估整個項目的代碼質(zhì)量的第一步是通過靜態(tài)代碼分析工具。使用工具（基于技術(shù)）如SonarQube，NDepend，F(xiàn)xCop，TFS代碼分析規(guī)則。有一個說法，靜態(tài)代碼分析工具是為了管理者。
2.使用插件，如Resharper，在Visual studio可以提供非常好的提醒。
3.跟蹤代碼審查注釋使用Crucible，Bitbucket和TFS代碼審查過程等工具。
結(jié)論
上述代碼審查清單并不詳盡，但是為代碼審查者提供了一個方向，以便進行有效的代碼審查并提供高質(zhì)量的代碼。起初，從各個方面審查代碼需要一些時間。經(jīng)過長期練習，代碼審閱者可以執(zhí)行有效的代碼審查，不需要太多的精力和時間。如果您想成為專家代碼審查人員，此代碼審查清單是一個很好的起點?？鞓反a審查！
譯自：http://www.evoketechnologies.com/blog/code-review-checklist-perform-effective-code-reviews/
轉(zhuǎn)自：https://mp.weixin.qq.com/s/9-lc16u-KcFbCCmymdLAbQ
轉(zhuǎn)自公眾號技術(shù)管理雜談：
