代碼審查規(guī)范

1、代碼審查規(guī)范1. Code ReVieW 目的Code ReVieW 是一種用來確認方案設計和代碼實現(xiàn)的質(zhì)量保證機制，通過這個機制我們可以對 代碼、測試過程和 注釋 進行檢查。Code ReVieW 主要用來在軟件工程過程中改進代碼質(zhì)量，通過Code ReVieW可以達到如下目的： 在項目早期就能夠發(fā)現(xiàn)代碼中的BUG o 幫助初級開發(fā)人員學習高級開發(fā)人員的經(jīng)驗，達到知識共享。 避免開發(fā)人員犯一些很常見，很普通的錯誤。 保證項目組人員的良好溝通。 項目或產(chǎn)品的代碼更容易維護。2. Code ReVieW的前提條件代碼提交審核前，開發(fā)者 必須確保代碼符合如下條件，審核者 需要確保所有前提條件都已滿

2、足方可開始審查，同時也是審查的主要檢查點。 所有代碼注釋清晰，語法正確，編譯通過。 日志代碼完整，業(yè)務日志、系統(tǒng)日志分開，中文描述，脫敏處理，狀態(tài)變更，全部清晰明確。Emma （各編譯器可下載對 測試代碼覆蓋全部分支和流程，暫時統(tǒng)一使用工具應插件）進行COVerage CheCk項目引用關系明確，依賴關系清晰，配置文件描述。3. Code ReVieW 的審查范圍代碼的一致性、編碼風格、代碼的安全問題、脫敏問題、代碼冗余、是否正確設計以符 合設計要求(性能、功能)與設計文檔相同等等。3.1、完整性檢查(Complete ness ) 代碼是否完全實現(xiàn)了設計文檔中所涉及的所有流程和功能點 代碼是

3、否已包含所有所需的業(yè)務日志、系統(tǒng)日志、異常日志，日志內(nèi)容是否完 整，日志文件配置是否正確。 代碼是否使用緩存等，配置信息是否正確可配置。 代碼中是否存在任何沒有定義或沒有引用到的變量、常數(shù)或數(shù)據(jù)類型等3.2、一致性檢查(Con SiSte ncy ) 代碼的邏輯是否符合設計文檔 代碼中使用的格式、符號、結(jié)構(gòu)等風格是否保持一致3.3、正確性檢查(COrreCt ness ) 代碼是否符合制定的標準 所有的變量都被正確定義和使用所有的注釋都是準確的所有的程序調(diào)用都使用了正確的參數(shù)個數(shù)3.4、可修改性檢查(Modifiability ) 代碼涉及到的常量是否易于修改(如使用配置、定義為類常量、使用專

4、門的常量類等) 代碼中是否包含了交叉說明或數(shù)據(jù)字典，以描述程序是如何對變量和常量進行 訪問的 代碼是否只有一個出口和一個入口(嚴重的異常處理除外)3.5、可預測性檢查( PrediCtabiIity ) 代碼所用的開發(fā)語言是否具有定義良好的語法和語義 是否代碼避免了依賴于開發(fā)語言缺省提供的功能 代碼是否無意中陷入了死循環(huán) 代碼是否避免了無窮遞歸3.6、健壯性檢查(RObUSt ness ) 代碼是否采取措施避免運行時錯誤(如數(shù)組邊界溢出、被零除、值越界、堆棧 溢出等)3.7、結(jié)構(gòu)性檢查(StrUCtUred ness ) 程序的每個功能是否都作為一個可辯識的代碼塊存在循環(huán)是否只有一個入口3.8

5、、可追溯性檢查( TraCeabiIity ) 代碼是否對每個程序進行了唯一標識 是否有一個交叉引用的框架可以用來在代碼和開發(fā)文檔之間相互對應 代碼是否包括一個修訂歷史記錄，記錄中對代碼的修改和原因都有記錄 是否所有的安全功能都有標識3.9、可理解性檢查(Un dersta ndability) 注釋是否足夠清晰的描述每個子程序 是否使用到不明確或不必要的復雜代碼，它們是否被清楚的注釋 使用一些統(tǒng)一的格式化技巧(如縮進、空白等)用來增強代碼的清晰度 是否在定義命名規(guī)則時采用了便于記憶，反映類型等方法 每個變量都定義了合法的取值范圍 代碼中的算法是否符合開發(fā)文檔中描述的數(shù)學模型3.10、可驗證性

6、檢查 (VerifiabiIity) 代碼中的實現(xiàn)技術是否便于測試 測試代碼是否正確，是否覆蓋所有流程4. Code ReVieW 的步驟目前Code ReVieW步驟暫定如下，試行一段時間再根據(jù)問題做調(diào)整1. 代碼編寫者和 代碼審核者 坐在一起，由 代碼編寫者按照設計文檔中的用例依次講解自己所寫的代碼和相關邏輯，可采用從前端到后臺的方式，例如從Web層->DAO 層。2. 代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現(xiàn)隱藏的bug ；代碼編寫者和代碼審核者都要對這些bug記錄在案，代碼編寫者修改后再次提交審核，代碼審核者對應bug記錄進行回驗。3. 代碼講解完畢后，代碼審核者

7、給自己安排幾個小時再對代碼審核一遍。代碼需要一行一行靜下心看。同時代碼又要全面的看，以確保代碼整體上設計優(yōu)良。4. 代碼審核者根據(jù)審核的結(jié)果編寫代碼“審核結(jié)果”并將“審核記錄”和“審核結(jié)果”提交至 GIT，審核記錄和 審核結(jié)果參見附錄I審核記錄、附錄II審核結(jié)果。5. 代碼編寫者GIT PUIl并根據(jù)“審核結(jié)果”給出的修改意見，修改好代碼，有不清楚的地方可積極向 代碼審核者 提出。6. 代碼編寫者bug fix等全部修改完成后提交代碼審核者再次進行審核，通過審核則代碼審核者更新本次審查結(jié)果并提交至 GIT，審核通過對代碼不能再進行修改，任何已通過審核的代碼修改必須重新進行審核流程。7. 代碼審

8、核者把COde ReVieW 中發(fā)現(xiàn)的有價值的問題更新到"代碼規(guī)范"的文檔中，對于特別值得提醒的問題可群發(fā)email或QQ給所有技術人員5. Code ReVieW 標準代碼審查的基礎是我們的設計文檔規(guī)范、代碼規(guī)范、日志規(guī)范、測試代碼規(guī)范，針對新 增的業(yè)務場景和設計尚未有規(guī)范對應時應先確立規(guī)范然后再進行代碼審核流程。6. Code ReVieW 注意點6.1.經(jīng)常進行 Code ReVieW 要ReVieW的代碼越多，那么要重構(gòu)，重寫的代碼就會越多。而越不被代碼編寫 者接受的建議也會越多，唾沫口水戰(zhàn)也會越多。建議每一個功能，每一個用例完成 后都可以進行審核，將大任務拆分為小

9、任務進行。 程序員代碼寫得時候越長，程序員就會在代碼中加入越來越多的個人的東西。 越接近軟件發(fā)布的最終期限，代碼也就不能改得太多。6.2. Code ReVieW不要太正式，而且要短CheCkliSt吧，走到你的同事座位跟前，像請師父一樣請他坐到你忘了那個代碼評審的給他另外一個5分鐘讓他給你的代碼CheCkIiSt，讓這個事情表現(xiàn)得很正式的的電腦面前， 然后，花5分鐘給他講講你的代碼， 提提意見，這比什么都好。而如果你用了一個話，下面兩件事中必有一件事會發(fā)生：只有在 CheCkIiSt 上存在的東西才會被ReVieW。Code ReVieWS變成了一種禮節(jié)性的東西，你的同事會裝做很關心你的代碼

10、，但其實他心里想著盡快地離開你只有不正式的Code ReVieW才會讓你和評審者放ReVieW 只不過是一種形輕松，人只有放松了，才會表現(xiàn)得很真實，很真誠。記住 式，而只有在相互信任中通過相互的討論得到了有意義和有建設性的建議和意見，那才是最實在的。不然，作者和評審者的關系就會變成小偷和警察的關系。6.3. 盡可能的讓不同的人ReiVeW 你的代碼如果可能的話，不要總是只找一個人來ReVieW你的代碼，不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個方面評論你的代碼。但不要太多了，人多嘴雜反而適得其反，基本上來說，不要超過3個人，這是因為，這是一個可以圍在一起討論的最大人

11、員尺寸。下面是幾個優(yōu)點： 從不同的方向評審代碼總是好的。 會有更多的人幫你在日后維護你的代碼。 這也是一個增加團隊凝聚力的方法。6.4. 保持積極的正面的態(tài)度程序員最大的問題就是自負”，尤其當我們 ReiVeW別人的代碼的時候，我已經(jīng)見過無數(shù)的場面，程序員在COde ReVieW的時候，開始抨擊別人的代碼，質(zhì)疑別人的能力。太可笑了，我分析了一下，這類的程序員其實并沒有什么本事，因為他們指責對方的目 的是想告訴大家自己有多么的牛，靠這種手段來表現(xiàn)自己的程序員，其實是就是傳說中 所說的“半瓶水”。所以，無論是代碼編寫者，還是代碼審核者，都需要一種積極向上的 正面的態(tài)度， 編寫者需要能夠虛心接受別人

12、的建議，因為別人的建議是為了讓你做得因為那是和你在一個戰(zhàn)壕更好；審核者也需要以一種積極的正面的態(tài)度向編寫者提意見， 里的戰(zhàn)友。記住，你不是一段代碼，你是一個人！6.5.學會享受 Code ReiVeW這可能是最重要的一個提示了，如果你到了一個人人都喜歡Code ReiVeW 的團隊，那么，你會進入到一個生機勃勃的地方，在那里，每個人都能寫出質(zhì)量非常好的代碼，在那里，你不需要經(jīng)理的管理，團隊會自適應一切變化，他們相互學習，相互幫助，不僅僅是寫出好的代碼，而且團隊和其中的每個人都會自動進化，最關鍵的是，這個是一個團隊。7. Code ReVieW 操作目前我們將Code ReVieW分為兩個階段，

13、開發(fā)互審和上級審查兩個階段。7.1開發(fā)互審任意兩名開發(fā)人員（建議不要固定配對，避免思維定勢）進行交叉代碼審查，代碼編寫者準備所開發(fā)的代碼相關的全部資料列表，包括需求、設計文檔、代碼工程、類、方法、配置文件、數(shù)據(jù)庫修改、數(shù)據(jù)修改等全部資料的版本號等詳細信息，向代碼審查者 全面介紹代碼的目標和設計實現(xiàn)。代碼審查者按照需求文檔、設計文檔、開發(fā)規(guī)范進行代碼（業(yè)務、日志、測試）審查，代碼審查者 將審查結(jié)果提交至 GIT，出現(xiàn)的問題由 代碼編寫者 進行修改并由 代碼審查者 復審，復審結(jié)果提交至 GIT保留。代碼審查者對所審查的代碼負責7.2上級檢查開發(fā)互審完成后，由上級進行上級審查，流程與開發(fā)互審 相同，

14、對于三次復審仍未通過的代碼需要代碼編寫者組內(nèi)進行檢討問題原因，并書面列出改進計劃。7.3沖突解決當開發(fā)互審 時對于檢查內(nèi)容出現(xiàn)爭議時由上級進行協(xié)調(diào)解決或逐級向上協(xié)調(diào)解決。當上級審查 時出現(xiàn)爭議時逐級向上協(xié)調(diào)解決。所有問題解決原則為公司利益、團隊利益、業(yè)務需求、設計文檔、規(guī)范文檔等為參考標準。附錄I審核記錄審核記錄如同修改記錄一樣，直接記錄入代碼頭部，代碼審核者 修改審核記錄后提交代碼至GIT參考即可。之后的審核可以基于兩次審核間的變更利用對比工具進行增量審核。可參考如下示例類：ngp_common/src/main/java/com/heepay/file/FileUtils.java代碼示例

15、：/*名稱：文件操作工具類*創(chuàng)建者：王曉 *創(chuàng)建時間：2016-06-21*創(chuàng)建描述：實現(xiàn)文件的創(chuàng)建、刪除、復制、壓縮、解壓以及目錄的創(chuàng)建、刪除、復制、壓縮解壓等功能*修改者：李宗杰*修改時間：2016-08-08*修改描述：添加注釋和代碼審核信息*修改者：*修改時間：*修改描述：*審核者：侯建春*審核時間：2016-08-08*審核描述：格式可以*一行寫不下再次一行*再來一行*審核者：李宗杰*審核時間：2016-08-08*審核描述：審核不通過，Iog沒有使用Iog4j2*審核者：*審核時間：*審核描述：*/附錄II審核結(jié)果審核結(jié)果建議以表格的形式描述，每個問題分別列出，可以通過標注行號來具體指明位置，給出合理的修改意見并說明標準。為了方便記錄和查詢以及代碼編寫者修改和復審，建議審核結(jié)果寫入COmmit message 中，由于 COmmit message只能提交文本，我們以軟表格的形式描述。對于COmmit message的書寫規(guī)范，查看參考。格式：docs （代碼審核）:審核通過doc