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

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

社區(qū)

Agile

主題

質(zhì)量交付

轉(zhuǎn)自: http://www.infoq.com/cn/news/2008/03/code-review-antipatterns

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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