什么是代碼評審(code review)? 根據維基百科的定義，代碼評審是一種通過若干人員檢閱源代碼方式來進行的軟體質量保證活動，根據軟體工程的經典理論，代碼評審應該是收益很高的活動，因其產生在Coding階段（屬于開發生命周期的早期），在開發生命周期越早發現問題，解決問題的成本越低，工程實踐也能印證這個結論， 代碼評審有以下目標：
- 提高代碼質量和可維護性（可讀性，一致性）
- 發現代碼缺陷
- 知識經驗傳承
- 發現更好的解決方案
- 滿足ＱＡ指導方針
本人根據針對網路上某代碼評審最佳實踐的公開文章談談自己的想法，
原則１：每次只評審小于２００～４００行的代碼，
－－》 我的觀點：這個只要是考慮到一次評審的代碼過多，評審者發現問題的能力將大量縮小，如果一次評審過多代碼，會對評審者帶來智力和心理兩方面的挑戰，從智力上來說，拋開極少數智力超群者不談，對普通人來說，一次評審更少量的代碼更容易理解代碼的意圖（同時減少了與代碼作者的溝通成本，提高效率），這也是符合分而治之的解決問題方法論的，從心理上來說，一次評審過多代碼會對評審者產生倦怠感，評審者主觀上通常會降低評審的細致度，根據我的經驗，如果某項軟體開發任務代碼量比較大，可將此任務分解為若干子任務，子任務的劃分粒度盡量做到一周的代碼提交量（提交的代碼需要測驗通過），當然，子任務的劃分是建立在良好的設計檔案基礎上，否則子任務劃分的隨意度比較高且作業量評估容易不準確，
原則２：代碼評審速度應小于每小時３００～５００行，
－－》 我的觀點：這條主要是考慮評審的細致度，細致度越高越能發現更多問題，換算一下，一個２０行的函式，評審時間應不少于２～４分鐘，
原則３：檢查清單（checklist）可以大幅改善評審結果
－－》 我的觀點：檢查清單對代碼作者和評審者都有作用，對代碼作者來說，可以在編碼的時候就犯止犯類似的錯誤，對評審者來說，可以幫助評審得更全面，特別是找出遺漏的問題，檢查清單可以定期更新，在評審程序中發現的問題都可以對照檢查清單，看看是否需要添加新的條目，最新的檢查清單需要在團隊內公布，最好是放在一個固定的位置方便隨時查看，這個檢查清單可以考慮和編碼規范放在一個檔案，互為對照補充，
原則４：團隊領導者應建立一種正面的評審文化，即應正面看待評審中發現的問題
－－》 我的觀點：為什么需要完全正面的看待在評審中發現的問題？如前文所述，在代碼評審中發現問題的修復成本非常低，所以發現越多問題越是好事，只有完全正面看待代碼評審發現的問題，評審者才會有更大的動機會發現更多的問題，對于代碼作者來說，在代碼評審中發現問題，可以幫助自己修正錯誤的編碼習慣和提高自身的編碼能力，同時，完全正面看待評審發現的問題，能使得評審者和代碼作者建立更為和諧的關系，更有利于發現更多問題，為了建立正面評審文化，領導者需要在團隊中宣貫在評審中發現問題表明代碼作者和評審者通過成功的團隊合作提高了代碼質量，領導者絕對不應將評審中發現的問題列入任何針對個人的考核因子，
原則５：輕量級的代碼評審是有效率的和現實的
－－》 我的觀點：軟體工程理論中非常正式的代碼評審一般要召集不同角色的工程師，通過召開會議來逐行審查代碼并進行討論，但是這種方式成本比較昂貴，較少有公司能夠負擔起這種人力成本，所以現今大部分公司都傾向于實施非正式的代碼評審，一般是基于工具，最簡單的非正式代碼評審可以是基于郵件串列，缺點是無法很好的記錄評審程序中的修改歷史和溝通資訊，幸運的是，現在有很多可以用于做代碼評審的工具，包括商業的和免費的，
另外，我想再做一些補充，對設計的評審應該基于設計檔案，在代碼評審階段去評審設計將會是低效的并且需要花費巨大的溝通成本，當然如果在代碼評審階段發現了設計的問題，需要回過頭去重新修改＆評審設計檔案，
綜上所述，輕量級的代碼評審對于業界大部分的軟體開發組織都是一個很好的選擇，是否在內部建立起正面的評審文化常常起決定性的作用，根據我的觀察，是否進行有效的代碼評審也基本上是區分二流軟體開發組織和三流軟體開發組織的一個明顯標志：）
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/981.html
標籤：其他
下一篇：TestLink使用指南