代碼走查指引

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