代碼走查指引

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