前端代碼質量保障之代碼review

經驗豐富的程序員和通常程序員之間的最大區別，不只體如今解決問題的能力上，
還體如今平常代碼的風格上。掌握一門技術可能須要幾月，甚至幾周就夠了。 
好的習慣風格養成卻需數年。


        團隊成員之間須要合做，代碼須要往後可維護，個體的能力和習慣存在差別。 
故保證代碼質量及風格，就須要制定必定的規則，按項目週期(最好是在上預發以前)組織進行集體代碼review。

一 目的

1    保證代碼質量 
        本身的代碼要給別人看，在開發過程當中就會刻意的注意一些規範，寫法及邏輯嚴謹性。

        2    扼殺潛在的風險
        程序員會去自測，即便有某種狀況分支遺漏, 在講解的過程當中其餘同窗也能發現。

        3    互相學習提升
        高手是如何寫出邏輯嚴謹，簡潔易懂的代碼的。方便對照本身的不足，逐步的糾正。

 

 

二 如何推進

1 分組結對

1  通常團隊大前端，後端 確定有多名同窗。
   能夠按‘同項目，模塊或老司機帶新’ 的模式進行分組。並指定各個小組組長(最好輪值)。

   2  小組長，負責開發過程當中規範提醒 及 發起相互review。

2 集體review

1  每次review最核心的代碼,控制好時間。

   2 各自講解本身的模塊，複雜業務最好配有流程圖。

3 開發工期

要把 ‘代碼review’及 代碼優化也評估進去。

4 打分制(下面會繼續 講解打分細則)

1  評判代碼好壞，仍是須要一個衡量標準，能夠採用打分制度。除同個項目組成員外其他項目組同窗，均要給該講解人打分。

   2  打分須要註明：一  須要修復和改進的地方； 二  值得學習借鑑的地方。
   並統一由會議記錄人，郵件抄送相關人員，開發者去落實修改，組長負責跟進驗收。

 

 

三 自查(測)清單

前面說了，要自測。那麼咱們大概能夠從以下方面切入：

1 常規項

1 代碼可以工做麼？它有沒有實現預期的功能(需求)，邏輯是否正確等。
2 全部的代碼是否簡單易懂？ 是否儘量的模塊化了？組件化了？是否存在多餘的或是重複的代碼？
是否有能夠被庫函數替代的代碼(儘可能用集團自有的)？ 不重複造輪子。
3 代碼符合你所遵循的編程規範麼(詳見 我另外html,js,css編碼規範的文章)？這一般包括大括號的位置，變量命名和函數名，行的長度，縮進，格式和註釋。
4 去掉大段被註釋掉的代碼(如有用能夠先提交到git上,之後可回滾)
5 循環是否設置了長度和正確的終止條件？ 按鈕是否有控制單次點擊,不重複提交？
6 是否有考慮調用api接口緩存問題？是否有能夠刪除的日誌或調試代碼？
……

2 安全

1 全部的輸入是否都進行了檢查（檢測正確的類型，長度，格式和範圍），考慮了xss攻擊和js腳本注入。

2 引用導入的第2、三方依賴包，是否存在不可用 和 版本升級致使功能不可用的風險。
是不是GPL協議的源碼( 不能用，不然會要求使用者的代碼也開源)

3 本機保存的數據，是否有泄漏的隱患。（銘感數據不作本地存儲，即便保存也須要加密)。

4 全部的請求連接是否都是用https，包括圖片地址。

5 發佈以前清理log日誌 和 敏感註釋。尤爲是前端同窗。

3 文檔

1 是否有註釋，而且描述了代碼的意圖？數據結構和計量單位是否進行了解釋？
2 對很是規行爲和邊界狀況處理是否有描述？
3 第三方庫的使用和函數是否有文檔？
4 是否有未完成的代碼？若是是的話，是否是應該移除，或者用合適的標記進行標記好比‘TODO’？

4 性能速度

1 頁面加載顯示是否超過3s(用戶超過3s 就會不耐煩，除非你有很友好的提示。。。)
2 js代碼 是否有明顯影響性能的邏輯 和 計算。
3 同個組件 或者 頁面佈局層級嵌套儘可能不要太深，保持簡潔性。

 

 

 

四 評分標準及規則 (5大維度，總分100)

1 需求功能覆蓋率 --------權重3（30%)

9-10分：代碼嚴謹、邏輯分支覆蓋全面 無遺漏
6-8分：無關鍵邏輯分支遺漏，普通遺漏不超過2次
0-5分：關鍵邏輯分支遺漏1次及以上 或其餘分支遺漏2次以上

2 代碼結構耦合度--------權重3（30%)

9-10分：結構清晰，模塊獨立（數據融合），模塊間關聯簡單，模塊內完成特定子功能
6-8分：模塊間中度藕合（控制藕合）
0-5分：模塊間強藕合，模塊內功能複雜

3 健壯性---------2(20%)

9-10分：性能穩定，異常考慮周全，沒有安全注入風險----1 頁面打開速度不超過3s 2 破壞性測試狀況下依然穩定加載
6-8分：異常處理不到位（undefined等），存在性能問題，但不影響關鍵流程，不宕機
0-5分：關鍵流程存在問題，有宕機風險

4 簡潔度------1(10%)

9-10分：沒有冗餘代碼，沒有重複造輪子，單個函數功能單一,建議不超過20行,無多餘導入的包或類
6-8分：存在冗餘，重複代碼
0-5分：廣泛存在冗餘，重複代碼

5 可讀性------1(10%)

9-10分：嚴格執行集團編碼規約，易於理解，命名規範，註釋清晰 
6-8分：存在閱讀障礙與閱讀困難的狀況
0-5分：關鍵邏輯與複雜代碼缺少註釋，理解極度困難

ps: 分數最終計算方式能夠這麼着
1 總分按100分算，單項最終得分=評分*權重 （例如‘覆蓋率項得總分27=9*3） ，而後把5項的總分加起來。



2 3.75的標準就是各項加起來90分+ ;3.5的標準就是加起來80分+

 

補充：
1    方法的請求  和  數據處理  儘可能分離, 抽離 (一個方法只作一件事情)。

2    相關對象，作下 容錯 或 默認值 處理。

3    主要review  1  異常狀況分析處理       2  主流程業務有無遺漏。