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