設計和代碼審查：是好、是壞還是不堪入目？

作者 Vikas Hazrati譯者 李劍 發布于 2008年3月10日 上午11時4分

社區

Agile

主題

質量交付

轉自: http://www.infoq.com/cn/news/2008/03/code-review-antipatterns

在一篇有關設計和代碼復查的文章中，Kirk Knoernschild提到，這種復查的承諾是改進軟件質量、確保與標準的一致性，并且可以作為一種有價值的工具為開發人員服務，但是它們的執行方式卻影響到了自身的價值。在某些組織中，它們可能真的見效；而在另一些地方，可能也不過是官僚作風的一種體現而已。

迫害式復查——編寫代碼的開發人員有被攻擊的感覺，甚感恐懼。

花括號復查——只強調排版結構和縮進之類的瑣碎細節，而置更為嚴重的問題于不顧。

盲查——復查人在參與復查之前從來沒有看過一眼代碼，并在未經準備的情況下參加復查會議。

排它性復查——只拿出代碼中的某一段樣本來進行復查，把其他重要的部分都棄而不顧。

樵夫式復查——一直等到代碼庫變成龐然大物再進行復查，而這時要進行完整的復查已經變成了難如登天且事倍功半的任務。

令箭式復查——將復查活動形式化，只因為是管理層打算這樣做。

世界性復查——在為數眾多且大部分都與項目無關的人士之前進行復查，并因此令開發者惶恐不安。

Kirk認為，為了進行有效的復查，團隊必須力求將復查過程做到自動化，同時收集一些度量標準。團隊還應該把反饋機制納入他們現有的開發環境中，這樣開發人員在準備提交代碼前就會收到自動警示提示。

他提到有些工具可以將復查過程變得更加客觀、關注點更為集中：

• JDepend，用于檢查設計質量
• PMD，用于檢查代碼整潔程度
• JavaNCSS，用于檢查代碼質量
• Emma，用于檢查測試覆蓋率

Kirk還提到了一種用來進行復查的有趣方式，名為20%復查：

20%復查的想法是很簡單的：一旦開發完成了20%，那么就應該進行一次復查。對有些團隊來說，在每一次迭代中都進行20%復查會收到顯著成效。它的效果 確實不錯，不過如果開發團隊可以成功地使用度量標準進行持續復查，那么針對每一個主要的系統功能進行20%復查就足夠了。

20%復查應當關注初始設計和代碼的整潔。在代碼庫大小相對易于管理時，上面提到的度量標準可以深入洞察代碼的演化和發展狀況。

他在文末又強調了要通過使用度量標準來將復查過程變得更具客觀性、關注點更集中的重要性，以此作為全文的收束。自動化程度越高，就越容易達到這些標準，然后就可以進行有效的復查。復查應該盡早進行，這樣開發者才能夠把早期的收獲用到開發過程中，復查的有效度不會受到損害。