CodeReview規范

目標和原則

• 提高代碼質量，及早發現潛在缺陷，降低修改/彌補缺陷的成本
• 促進團隊內部知識共享，提高團隊整體水平
• 評審過程對於評審人員來說，也是一種思路重構的過程，幫助更多的人理解系統
• 是一個傳遞知識的手段，可以讓其它並不熟悉代碼的人知道作者的意圖和想法，從而可以在以后輕松維護代碼
• 可以被用來確認自己的設計和實現是一個清楚和簡單的
• 鼓勵相互學習對方的長處和優點
• 高效迅速完成Code Review

  Code Review Checklist

  Code Review主要檢查代碼中是否存在以下方面問題：
  代碼的一致性、編碼風格、代碼的安全問題、代碼冗余、是否正確設計以滿足需求（功能、性能）等等

  • 完整性檢查
    • 代碼是否完全實現了設計文檔中提出的功能需求
    • 代碼是否已按照設計文檔進行了集成和Debug
    • 代碼是否已創建了需要的數據庫，包括正確的初始化數據
    • 代碼中是否存在任何沒有定義或沒有引用到的變量、常數或數據類型
  • 一致性檢查
    • 代碼的邏輯是否符合設計文檔
    • 代碼中使用的格式、符號、結構等風格是否保持一致
  • 正確性檢查
    • 代碼是否符合制定的標准
    • 所有的變量都被正確定義和使用
    • 所有的注釋都是准確的
    • 所有的程序調用都使用了正確的參數個數
  • 可修改性檢查
    • 代碼涉及到的常量是否易於修改(如使用配置、定義為類常量、使用專門的常量類等)
    • 代碼中是否包含了交叉說明或數據字典，以描述程序是如何對變量和常量進行訪問的
    • 代碼是否只有一個出口和一個入口（嚴重的異常處理除外）
  • 可預測性檢查
    • 代碼所用的開發語言是否具有定義良好的語法和語義
    • 是否代碼避免了依賴於開發語言缺省提供的功能
    • 代碼是否無意中陷入了死循環
    • 代碼是否是否避免了無窮遞歸
  • 健壯性檢查
    • 異常處理和清理（釋放）資源
    • 代碼是否采取措施避免運行時錯誤（如數組邊界溢出、被零除、值越界、堆棧溢出等）
  • 結構性檢查
    • 程序的每個功能是否都作為一個可辯識的代碼塊存在
    • 循環是否只有一個入口
  • 可追溯性檢查
    • 代碼是否對每個程序進行了唯一標識
    • 是否有一個交叉引用的框架可以用來在代碼和開發文檔之間相互對應
    • 代碼是否包括一個修訂歷史記錄，記錄中對代碼的修改和原因都有記錄
    • 是否所有的安全功能都有標識
  • 可理解性檢查
    • 注釋是否足夠清晰的描述每個子程序
    • 是否使用到不明確或不必要的復雜代碼，它們是否被清楚的注釋
    • 使用一些統一的格式化技巧（如縮進、空白等）用來增強代碼的清晰度
    • 是否在定義命名規則時采用了便於記憶，反映類型等方法
    • 每個變量都定義了合法的取值范圍
    • 代碼中的算法是否符合開發文檔中描述的數學模型
  • 可驗證性檢查
    • 代碼中的實現技術是否便於測試
  • 可重用性
    • DRY（Do not Repeat Yourself）原則：同一代碼不應該重復兩次以上
    • 考慮可重用的服務，功能和組件
    • 考慮通用函數和類
  • 可擴展性
    • 輕松添加功能，對現有代碼進行最小的更改。一個組件可以被更好的組件替換
  • 安全性
    • 進行身份驗證，授權，輸入數據驗證，避免諸如SQL注入和跨站腳本（XSS）等安全威脅 ，加密敏感數據（密碼，信用卡信息等）
  • 性能
    • 使用合適的數據類型，例如StringBuilder，通用集合類
    • 懶加載，異步和並行處理
    • 緩存和會話/應用程序數據

  代碼檢查包括不局限於上述清單，提交人應在本地自我完成代碼格式、架構設計、面向對象分析與設計等檢查。
  備注：

  • Java服務端開發必須遵循阿里巴巴Java開發手冊（終極版）,IDEA中安裝相關插件有告警提示不允許提交合並

  Code Review的步驟

  1. 代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UC依次講解自己負責的代碼和相關邏輯，從Web層->DAO層；
  2. 代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發現隱藏的bug；對這些bug記錄在案。
  3. 代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要一行一行靜下心看。同時代碼又要全面的看，以確保代碼整體上設計優良。
  4. 代碼審核者根據審核的結果編寫“代碼審核報告”，“審核報告”中記錄發現的問題及修改建議，然后把“審核報告”發送給相關人員。
  5. 代碼編寫者根據“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。
  6. 代碼編寫者 bug fix完畢之后給出反饋。
  7. 代碼審核者把Code Review中發現的有價值的問題更新到"代碼審核規范"的文檔中，對於特別值得提醒的問題可群發email給所有技術人員。

  備注：
  Code Review必備的文檔：
  “Code Review規范”文檔：記錄代碼應該遵循的標准。
  代碼審核者根據這些標准來Code Review代碼，同時在Code Review過程中不斷完善該文檔。

  Code Review的執行

  准備階段

  1. 評審規范和標准
  2. 在CR前設計確定評審規范和標准是必要，通過規范和標准我們在審查過程中可以有據可依，有理可循，而且還可以做到標准統一。
  3. 選擇CR活動的參與者
  4. 在CR開始前，必須把本次CR活動的對象、審查內容以及審查的規范和標准通過email通報給所有的參與者。
  5. 選擇CR活動的實施方式
  6. CR活動有很多形式可供我們選擇，我們可以根據實際情況選擇桌面式CR、演示講解式CR、一對一的座位CR等等。(一般按新增功能桌面式CR、里程碑功能演示講解式CR、BUG修復一對一的座位CR)

  實施階段

  充分的事前准備，只是做好CR活動的前提，在CR實施過程中，我們要做好以下工作。

  1. 准確記錄
  2. 對於CR過程發現的問題，我們必須清晰准確的記錄，可以使用問題點記錄單，明確記錄的項目和內容。
  3. 講解與提問
  4. CR過程中，要采用代碼作者講解和審查者提問方式。審查者不能只在發現問題時提問，同時也要根據本次審查的內容要求代碼作者對某個特定問題的講解。
  5. 逐項審查
  6. 對事前確定的審查內容，要逐項審查，不能因為時間不足等因素一掃而過。
  7. 注意氣氛
  8. 實施審查時，要營造一個討論問題、解決問題的氛圍，不能把審查會搞成批判會，這樣會影響相關人員的積極性。

  事后跟蹤

  1. 確認發現的問題 CR結束后，對發現的問題，首先需要確定以下內容。
  2. 問題點的難易程度以及影響的范圍；
  3. 解決問題的責任者和問題點修正結果的確認者；
  4. 解決問題點的時限。
  5. 修正問題責任者 對於修正問題責任者，在問題點的修正過程中，要三方面內容的記錄。問題點的原因；
  6. 解決問題點的對策；
  7. 修正的內容。