11個高效的同行代碼評審最佳實踐(4)

　　回頁首

　　10. 評審一部分的代碼，就算您不能全部完成，以從自我效能感(Ego Effect)中獲益

　　想象一下您自己坐在編譯器的前面，任務是需要修復一個小小的錯誤(bug)。但是您知道只要您說出了“我完成了”，您的同行 — 或者更糟，您的老板 — 就要檢查您的工作了。這會改變您的開發個性嗎?所以在您工作時，一般是在您聲明代碼評審完成之前，就會更加的謹慎了。如此您立即就會成為一個更好的開發員了，因為在您背后別人議論您時就會說，“他的員工非常謹慎，他真是一個不錯的開發員”;而不是“他犯了大量愚蠢的錯誤(bug)。當他說工作完成時，實際上還差著遠呢”。

　　自我效能感(Ego Effect)會促使開發員編寫更好的代碼，因為他們知道其他人將會查看自己編寫的代碼及作品。沒有人想被其他人認為自己經常犯初級的錯誤(bug)。Ego Effect 促使開發員在向其他人交付作品時更加謹慎地進行評審。

　　Ego Effect 的一個良好特征，是不管評審者要對所有的代碼變更負責，還是僅僅執行“點檢查”，就像隨機性的藥物測試一樣，都能正常地發揮作用。如果您的代碼有三分之一的幾率被評審者抽中進行評審，那么它仍然足以刺激評審者謹慎工作。如果您只有十分之一的概率被抽中檢查，那么可能您就不會如此勤奮了。您知道您會說，“哈，我很少犯錯”。

　　評審 20–33% 的代碼時，從 Ego Effect 中獲得花費時間方面的收益可能最大，評審 20% 的代碼肯定要比不評審強很多。

　　回頁首

　　11. 采用輕量級，工具支持的代碼評審

　　代碼評審一般有些主要的類型和無數的變數，而指南卻能適用它們中的任何一個。但是，為了完全優化團隊花在評審之上的時間，我們要使用工具支持的輕量級評審過程來得到最優的結果。搜索缺席時，它是有效的，實用的。

　　規范，或者 重量級的 檢查已經流行了 30 年。它已經不是評審代碼的有效形式了。重量級檢查平均花費的時間是每 200 行代碼 9 個小時。盡管它很有效，但是嚴格的過程需要三到六個參與者，并進行一系列繁瑣的會議以討論具體的細節。不幸的是，盡管需要繁瑣的過程，但是大多數的公司沒有條件將編程人員集成起來,進行長時間的會議。最近的幾年，許多開發公司已經完全放棄了會議安排，紙質代碼閱讀，以及繁瑣的作品收集工作，轉而采用新型 輕量級 過程，以從規范的會議及老式重量級過程的重壓中解放起來。

　　我們使用在 Cisco 中的案例研究，來確定輕量級技術與規范過程比較的特點。結果顯示輕量級代碼評審所需要的時間只是規范評審的五分之一(甚至更少)，而且前者能夠發現更多的錯誤(bug)。

　　盡管輕量級代碼評審擁有很多的方法，例如實時評審和電子郵件評審，但是最有效的評審方法還是使用協作性的軟件工具來促進評審，這些軟件工具例如 SmartBear 的 CodeCollaborator(見于圖 4)。

　　圖 4. Cisco 研究中所使用到的輕量級代碼評審工具，CodeCollaborator

　　圖 4 的大圖

　　CodeCollaborator 是與 IBM® Rational Team Concert 工作流程相集成的唯一代碼評審工具。它將源代碼評審與聊天形式的協作集成起來，從而使開發員從聯系注釋與私人代碼行的繁瑣活動中解放了出來。當程序員向工作項添加更改項進行評審時，在 CodeCollaborator 中將會自動創建評審，并分配適當的批準者。團隊成員可以直接注釋代碼，與代碼開發者聊天，并就每一個問題進行協作，追蹤錯誤(bug)并修復缺陷。整個過程不需要會議，打印，或者安排日程。

　　有了基于 Rational Team Concert 與 CodeCollaborator 的輕量級評審過程，團隊就可以進行更有效的評審，并實現代碼評審的有利點。

	CodeCollaborator 獲得了 "Ready for IBM Rational Software" 針對 Rational Team Concert V2 和 V3 的認證，以及針對 IBM® Rational® ClearCase® 和 IBM® Rational® Synergy® 的認證。

　　到現在為止，您已經被經實踐證明有效的經驗從頭到尾武裝起來了，以確保從過程和社會的角度來看，團隊在代碼評審過程之中能夠節省大量的時間。當然，您必須確實 完成了 代碼評審，以實現這些便利。對 100% 的代碼使用評審的規范方法(有人對這個百分比存在異議，簡單來說是不現實的。集成到 Rational Team Concert 環境之中的工具支持輕量級代碼評審，提供了最強大的功能，因為它提供了一個有效的方法去搜索缺陷，而且不會涉及到開發員頭痛的一些問題。有了正確的工具和這些實踐方式，您的團隊就可以對所有的代碼進行同行評審，并在軟件達到 QA 階段之前就找到成本極高的錯誤(bug)，這樣您的客戶每次都能夠得到頂級品質的產品了。

　　為了方便您查看，下面總結了在一個簡單列表中最容易保持的 11 項實踐方式：

　　一次評審少于 200–400 行的代碼。

　　目標為每小時低于 300–500 LOC 的檢查速率。

　　花足夠的時間進行正確緩慢的評審，但是不要超過 60–90 分鐘。

　　確定代碼開發者在評審開始之前就已經注釋了源代碼。

　　為代碼評審和獲取制度建立可定量化的目標，這樣您才能改進流程。

　　使用檢查列表，因為它可以極大地改進代碼開發者和評審者的作品。

　　確認缺陷確實得到修復了。

　　培養良好的代碼評審文化氛圍，在這樣的氛圍中搜索缺陷被看做是積極的活動。

　　警惕“老大”效應。

原文轉自：http://www.ibm.com/developerworks/cn/rational/11-proven-practices-for-peer-review/