代碼走查指引目標通過代碼走查把控代碼風格及設計要求。經驗表明，使用代碼走查方法能夠有效地發現30%到70%的深層次邏輯設計和編碼錯誤，是一種無法替代的提高軟件質量的研發活動。同時代碼走查對提高程序員的技術水平也非常有幫助，是一種非常高效的、團隊成員之間相互學習的方法，會在幾方面上幫到開發團隊：一次代碼審查可以將增、刪、改等功能性改動清楚明了地傳達給團隊成員，以便其開展后續的工作審查者可以學習到提交者所使用的某種技術或算法。更概括的說，代碼審查有助于組織內部的質量提升審查者可能掌握著能夠改善或精簡所提交代碼的編程技術知識或代碼庫；舉例來說，某人也許正好也在開發類似的特性或修復類似的問題積極的交互和溝通會加強團隊成員之間的社交連結代碼庫中的一致性讓代碼易讀易懂，有助于預防bug，并能促進開發者之間的合作代碼片段的易讀性對于將其親手寫出的作者來說是難以判斷的，而對于沒有完整上下文概念的審查者則容易的多。易讀的代碼更容易復用、bug較少，也更不易過時意外錯誤(如錯別字)及結構錯誤(像是無效代碼、邏輯或算法錯誤、性能或架構上的關注點)經常更容易被旁觀者清的挑剔審查者找出來。有研究顯示，即便是簡短、非正式的代碼審查也能顯著影響代碼質量和bug的出現的頻次合規合法的環境通常需要審查。代碼審查是避免常見安全陷阱的很好途徑原則通過MR來進行代碼評審活動。盡早開始代碼評審，早期的評審可以看作是設計評審。盡早給出評審意見，建議不超過3個工作日。一個MR不要有多個任務，除非它們是緊密關聯的一次評審少于200–400行的代碼。被評審的代碼必須編寫了測試。檢查結果的內容可以加入到開發規范中，并考慮用工具來實現自動化檢查。規范評審關注點測試代碼是否可以測試？比如，不要添加太多的或是隱藏的依賴關系，不能夠初始化對象，測試框架可以使用方法等。是否存在測試，它們是否可以被理解？是否包含了正確路徑、異常情況的測試？還有沒有其它場景需要納入進來？測試覆蓋率是否沒有下降？單元測試是否真正的測試了代碼是否可以完成預期的功能？是否檢查了數組的“越界“錯誤？常規項代碼能夠工作么？它有沒有實現預期的功能，邏輯是否正確等。代碼是否盡可能的模塊化了？是否有可以被替換的全局變量？是否有被注釋掉的代碼？循環是否設置了長度和正確的終止條件？是否有可以被庫函數替代的代碼？是否有可以刪除的日志或調試代碼？安全所有的數據輸入是否都進行了檢查（檢測正確的類型，長度，格式和范圍）并且進行了編碼？在哪里使用了第三方工具，返回的錯誤是否被捕獲？輸出的值是否進行了檢查并且編碼？無效的參數值是否能夠處理？文檔所有的函數都有注釋嗎？對非常規行為和邊界情況處理是否有描述？第三方庫的使用和函數是否有文檔？是否有未完成的代碼？如果是的話，是不是應該移除，或者用合適的標記進行標記比如‘TODO’？可讀性與可維護性命名是否足夠清晰的描述了變量、方法、類的含義與用途是否有注釋，并且描述了代碼的意圖或業務規則，而非if...then...的簡單描述？能夠很快看明白方法的目的么？異常信息能夠看明白嗎？所有的代碼是否簡單易懂？是否存在多余的或是重復的代碼？推薦實踐通過創建MR來開是一個評審過程。盡早創建MR，如果設計方面需要多方意見，甚至可以創建完分支即開啟MR。未完工的MR加上WIP:前綴，表明workinprogress。如果CI結果失敗，不用浪費時間做評審。每一個代碼工程，根據工程特點，維護一個OWNER列表，用于MR創建時，自動分配reviewer。被分配到MR時，reviewer會收到自動發出的通知，reviewer盡早開展評審活動，建議不晚于3個工作日給出意見與清單。問題清單應當創建到具體的代碼文件或者代碼行，便于交流。針對評審人提出的清單，被評人在解決完后，需要回復，以通知評審人哪些問題得到了修正。清單的狀態由評審人改變。全部解