代碼質量控制

代碼質量控制

常規三板斧：靜態檢查 代碼review 單元測試

靜態檢查，以前寫過工具sonar，以及操做流程。此次紀錄下reivew與單元測試。

單元測試

獲得更易於測試的代碼而且幫助設計，改的動代碼，能快速驗證。單純追求覆蓋率不是關鍵。

見過實施tdd atdd流於形式，爲了保證覆蓋率，欺騙性的各類手段經過，簡直無法看。

讓改代碼驗證，不須要要把依賴的各類東西都啓動好才能肯定這行代碼是否能沒問題能夠提測。

代碼review

自己是一種知識傳遞過程，代碼質量把控。既然是知識傳遞，就跟人有很大關係。

若是是水平接近，最後基本就是瞅下就過，你們都知道對方的水平線，有沒有這個流程都無所謂。

有差距的代碼reivew，這個過程很耗費精力，並且也在於你想怎麼要求別人，是知足90%仍是60%就行。

舉個例子：曾遇到過花費大量時間講代碼應該怎麼寫，怎麼設計，怎麼作，解惑對方各類問題，舉出各類場景，而後對方聽完後表示的缺應該如此，而後繼續不改，固然這裏面缺乏有效跟蹤，更沒有權限控制，在代碼裏繼續玩本身的，悲傷那麼大。

至於review工具方式，細力度分角色控制固然好，若是是趕時間，控制核心流程關鍵點吧。跟蹤機制在細力度狀況下，經過gitlab提供的角色活着pull request，粗力度就wiki 郵件跟蹤吧。

梳理核心流程，對系統影響很大關鍵路徑。

ps：最近在趕一個工期很是緊的平臺產品，涉及舊代碼複用，關於質量控制，代碼reivew作粗力度的控制，因爲人員水準，保障質量平均線以上。