記住這些錯誤(bug)通常不是在 Rational Team Concert 日志中輸入的,因為在代碼發布給 QA 之前就發現了這些錯誤(bug)。所以,什么是代碼在貼上“全部解決”標志之前確認缺陷的好辦法呢?我們建議使用好的協作性評審軟件,與 Rational Team Concert 相集成,以追蹤評審之中所發現的缺陷。有了正確的工具,評審員就可以記錄錯誤(bug),并在必要時與代碼開發者進行討論了。然后代碼開發者會修復問題,并通知評審者,而評審者必須確認每個問題都得到了解決。工具應該追蹤評審期間所發現的問題,并確保直到所有的錯誤(bug)被評審者 修復 才完成評審(或者作為稍后解決的單獨工作項追蹤)。工作項只有在評審完成時才能通過。
如果您真面臨著搜索錯誤(bug)的煩惱,那么請確認您已經將它們全部安裝了! |
既然您已經學會了代碼評審 流程 的最佳實踐方式,那么我們接下來將會討論一些社會效應,以及怎樣管理它們以獲得最佳的結果。
回頁首
8. 培養良好的代碼評審文化氛圍,在這樣的氛圍中可以積極地評審缺陷
與其他我們能看到的大多數技術相比,代碼評審對于真實團隊構建能夠發揮更大的作用,但是只是在管理人員能夠以一種積極的,向上的,有技巧的方式進行交流時,這種優勢才能發揮出來。將缺陷看做是不好的事物很容易(畢竟,它們是代碼之中的錯誤(bug)),但是形成不好的缺陷檢查態度,則會毀掉整個團隊的努力,更不要說它會破壞錯誤(bug)檢查過程了。
軟件代碼評審的要點在于,盡可能多的消除缺陷,不管是誰“導致”了錯誤(bug)。 |
管理人員必須建立缺陷是積極的這樣的觀點。畢竟,每一個缺陷的存在,都是改進代碼的潛在機會,而錯誤(bug)評審過程的目的,就在于使代碼盡可能地完美。每一個被發現并解決的缺陷,都是客戶以后不會看到的缺陷,也是 QA 人員不必花費時間去解決的問題。
團隊需要維持這樣一種態度,就是發現缺陷,就意味著代碼開發者和評審者 作為一個團隊 去改進產品的質量成功了。而不是“代碼開發者產生了一個缺陷,而評審者負責去發現它”。它更像是配對編程的一種有效形式。
評審員要向所有的開發者展示收集壞習慣,學習新技巧,并展開功能的機會。開發員可以從他們的錯誤(bug)中學習,但是只是在他們警惕錯誤(bug)時才會這樣。如果開發員害怕發現錯誤(bug),那么積極的結果就會消失。
如果您是一名初級開發員,或者是一個團隊的新成員,那么其他人發現缺陷時,就意味著您強有力的隊友在幫助您成長為一個合格的開發員。這就比您單槍匹馬地編程,沒有具體的反饋時,要更快地進步。
為了維持檢查缺陷是積極的這樣一種理念,管理人員必須要承諾缺陷密度不會進入到性能報告之中。公開作出這種承諾是很有效的。這樣開發員就會知道他們要怎樣做,并抗議公開破壞這條規則的管理人員。
管理人員絕不應該將錯誤(bug)代碼作為消極性能評審的基礎。他們必須謹慎對待,并對批評造成的挫折感及消極反應保持敏感,并要一直提醒團隊發現錯誤(bug)是一件很好的事情。
回頁首
9. 警惕老大哥效應(Big Brother Effect)
作為一個開發員,您可以自動假設“老大哥正看著您呢”是真的,如果評審制度是由評審支持工具自動評價的,更是這樣的。您是否花費了很長的時間去評審一下更改?您的同行從您的代碼中是否發現了很多錯誤(bug)?這將如何影響您下一步的性能評價?
評估報表不應用來對付開發人員,尤其是在面對結對評審員時。這一做法會嚴重破壞道德觀。 |
制度對于流程評價來說非常重要,這反過來,又為流程改進提供了一個基礎。但是制度也可以被用來做壞事。如果開發員相信制度是用來對付他們的,那么他們不光是對流程有敵意,而且他們的注意力可能轉到改變制度,而不是編寫更好的代碼,和變得更有效率上。
管理員可以做很多事情,來解決這個問題。首先也是最重要的,他們必須要警惕這一點,并且必須確定代碼開發者沒有面臨很多的壓力,而“老大哥”問題必須每次都得到詳細的檢查。
制度應該用來評價流程的效率,或者流程更改的效果。記住,通常來說,最困難的代碼是由最有經驗的開發員處理的。這些代碼,反過來,最有可能出問題,因此最難檢查,也有可能發現最多的缺陷。因此,大量的缺陷很有可能是由復雜性,以及代碼的分塊性造成的,而不是代碼開發者的能力造成的。
如果制度確實能夠幫助一個管理員去發現一個問題,那么將某人踢出局可能會產生更多的問題。我們推薦管理員在解決相關問題時,要將一個小組當做整體來對待。所以最好不要召開專門的會議,因為開發員在解決特定的問題可能會有壓力。相反,您可以通過一個每周狀態會議,或者正常的程序來解決問題。
管理員必須不斷地維持這樣一個年頭,即搜索缺陷是好的事情,而不是糟糕的,缺陷密度與開發員的能力并不是掛鉤的。記住對一個團隊來說,缺陷,尤其是團隊成員所引入缺陷的數量不應該被回避,也不應該用作能力的評價參數。
原文轉自:http://www.ibm.com/developerworks/cn/rational/11-proven-practices-for-peer-review/