代碼審查（Code Review)是軟件開發中常用的手段，和QA測試相比，它更容易發現和架構以及時序相關等較難發現的問題，還可以幫助團隊成員提高編程技能，統一編程風格等。
一．審查原因（Why）
持續、有效的開展代碼走查，將會收獲許多收益，具體表現在：
l 能及時發現代碼中的Bug，保證版本質量。
l 提升代碼的可讀性、可維護性，建立團隊共同的編碼風格。
l 有利於知識共享，打破技能壁壘，避免單點故障。
l 通過展示自己的優秀代碼和設計思路，提升了個人成就感。
l 通過講解自己的代碼，對個人溝通能力也是一種提升。
l 提高開發者的對編碼的責任感。
二．審查對象內容（What）
前后端所有研發人員審查周期內提交的代碼及數據庫腳本
如代碼數量過多可挑選部分重要功能模塊進行
三．審查人員（Who）
代碼走查不只是開發人員的事情！需要多種角色同時參與，因為走查活動不僅僅要看功能是否實現了，還要看代碼和設計是否一致？測試用例是否完備和有效？
1. 主持人（老王）
負責主持整個走查活動，控制時間和進度。
2. 講解人（被審查研發人員）
負責對走查的代碼進行講解。
3. 評審人（其他研發人員，測試，UI）
負責對走查代碼提出問題，建議。
四．審查地點（Where）
公司會議室
五．周期計划（When）
一周一次，時間每周四下午17:30
六．審查規范方法（How）
6.1編碼習慣：（關注點-框架使用與基本功）
l css、js、image等靜態文件應該放在約定的目錄里面。
l 在頁面中盡量避免寫入行內樣式，即style=“”。
l js語法中語句結束采用分號結尾，變量聲明后必須用分號結尾。
l 單行注釋語句規則：雙斜杠后必須跟一個空格、縮進與下一行保持一致。
l 多行注釋語句規則：對難以理解的代碼段或者可能存在錯誤的代碼段等可以采用多行注釋（/* */），每一行以*開頭，並且*后跟一個空格。
l 引號規則：一句代碼中只使用一種引號則雙引號優先，否則同意最外層使用單引號。
l 變量命名：變量采用駝峰式命名且首字母小寫（除了對象的屬性以外），定義后沒有被使用的變量要刪除。
l 函數規則：無論是函數聲明還是函數表達式，“(”前不要空格，但‘’{‘’前一定要有空格。函數調用括號前不需要空格，立即執行函數外必須包一層括號。
l 數組、對象的規則：兩者最后均不要有多余的逗號；對象以縮進的格式書寫，切忌書寫在同一行；對象屬性名不需要加引號。
l 在同一個函數內部中，局部變量的聲明必須定義在頂端。
l 除了三目運算符外，其他的（if、else等）禁止簡寫。如果if (true) alert("alert")。
l 在需要以為{ }閉合的代碼段前增加換行，如for、if。
l 不允許把多個短語句寫在一行中，即一行只寫一行數據。
l 函數中傳入的參數必須具有有效性，對特殊的入參必須進行說明。
l 盡量減少循環嵌套層次，盡量避免大於三層的循環。
6.2業務實現：（關注點-設計思路與業務邏輯）
l 如果類似的邏輯被使用了多次，應該把它寫成一個函數，然后再多處調用。
l 如果類似的邏輯被多個模塊使用且沒有復雜的關聯性，應該把它寫入靜態js文件，然后在使用到的模塊中進行引用后再使用。
l 強制代碼中禁止出現IP地址，以便在三個環境當中均可以正常使用。
l 強調代碼的單元測試
l 任何新加的代碼不應該破壞已有的代碼。
6.3安全：（關注點-系統安全性sql注入等）
l 任何代碼都不能執行用戶的輸入，除非轉義過了。這個常常包含 JavaScript 的 eval 函數和 SQL 語句。
l 對於那些在短時間內提交非常多請求的方法，可以采用防抖或者節流來控制請求次數，或者采用loading來阻止用戶多次點擊。
l 發生故障時，盡量少的暴露問題所在，只向用戶返回一般的信息，比如登陸失敗不應區分具體失敗原因（用戶名不存在、密碼錯誤、密碼已過期等），應采用統一的失敗提示（錯誤的用戶名或密碼）。
l 頁面標簽中應該盡量避免使用 iframe。
6.4性能：（關注點-系統運行消耗和可擴展性）
l 所有不需要的變量應該及時的刪去；盡量減少閉包的使用；如果在代碼中使用了閉包，則必須在退出函數之前，將不使用的局部變量全部刪除，或者將變量賦值為null。
l 盡量合並和壓縮css以及js文件以減少http請求次數以及減少請求資源的大小。
l 盡量使用字體圖標或SVG圖標來代替傳統的png圖。因為字體圖標或者SVG是矢量圖，是由代碼編寫出來的，放大后不會變形，而且渲染速度快。
l 避免使用iframe，不僅不好管控樣式，而且相當於在本頁面又嵌套其他頁面，消耗性能會更大（加載其他頁面的資源）。
l 樣式中給圖片設置尺寸。如果圖片不設置尺寸，首次載入時，占據空間會從0到完全出現，上下左右都可能位移，發生回流。
l 注意控制Cookie大小和污染，因為Cookie是本地的磁盤文件，每次瀏覽器都會去讀取相應的Cookie，所以建議去除不必要的Coockie，使Coockie體積盡量小以減少對用戶響應的影響。
6.5注釋：（關注點-代碼可讀性注釋清晰完善）
l Js單行注釋：在代碼上面注釋，必須獨占一行。// 后跟一個空格，縮進與下一行被注釋說明的代碼一致。
l Js后綴注釋：在一段語句后面后綴進行注釋， // 前后都跟一個空格，用於對某個語句的說明。
l 在有處理邏輯的代碼中，代碼有效注釋量必須在20％以上。
l 文件注釋：文件注釋（包括作者, 依賴關系和兼容性信息等）寫在文件頭部。
l 注釋的內容要清楚、明了，含義准確，防止注釋二義性。說明：錯誤的注釋不但無益反而有害。
l 對變量的定義和分支語句（條件分支、循環語句等）必須編寫注釋。
6.6新技術（關注點-適用性和擴展學習）
l 代碼使用新技術是否有效，是否最優，一起討論學習
推薦閱讀
【遠程醫療】互聯網醫院 衛健委數據上報平台技術方案
【技術選型】你的公司，你的項目真的適合微服務嗎？
【划划重點】論大數據中主數據的重要性
【視頻問診】ffmpeg+HLS直播與回放技術
【遠程醫療】智能導診技術方案