代碼靜態測試:高效同行代碼評審最佳實踐(3)

　　如果您真面臨著搜索錯誤(bug)的煩惱，那么請確認您已經將它們全部安裝了!

　　既然您已經學會了代碼評審流程 的最佳實踐方式，那么我們接下來將會討論一些社會效應，以及怎樣管理它們以獲得最佳的結果。

　　8. 培養良好的代碼評審文化氛圍，在這樣的氛圍中可以積極地評審缺陷

　　與其他我們能看到的大多數技術相比，代碼評審對于真實團隊構建能夠發揮更大的作用，但是只是在管理人員能夠以一種積極的，向上的，有技巧的方式進行交流時，這種優勢才能發揮出來。將缺陷看做是不好的事物很容易(畢竟，它們是代碼之中的錯誤(bug))，但是形成不好的缺陷檢查態度，則會毀掉整個團隊的努力，更不要說它會破壞錯誤(bug)檢查過程了。

　　軟件代碼評審的要點在于，盡可能多的消除缺陷，不管是誰“導致”了錯誤(bug)。

　　管理人員必須建立缺陷是積極的這樣的觀點。畢竟，每一個缺陷的存在，都是改進代碼的潛在機會，而錯誤(bug)評審過程的目的，就在于使代碼盡可能地完美。每一個被發現并解決的缺陷，都是客戶以后不會看到的缺陷，也是 QA 人員不必花費時間去解決的問題。

　　團隊需要維持這樣一種態度，就是發現缺陷，就意味著代碼開發者和評審者作為一個團隊去改進產品的質量成功了。而不是“代碼開發者產生了一個缺陷，而評審者負責去發現它”。它更像是結對編程的一種有效形式。

　　評審員要向所有的開發者展示收集壞習慣，學習新技巧，并展開功能的機會。開發人員可以從他們的錯誤(bug)中學習，但是只是在他們警惕錯誤(bug)時才會這樣。如果開發人員害怕發現錯誤(bug)，那么積極的結果就會消失。

　　如果您是一名初級開發人員，或者是一個團隊的新成員，那么其他人發現缺陷時，就意味著您強有力的隊友在幫助您成長為一個合格的開發員。這就比您單槍匹馬地編程，沒有具體的反饋時，要更快地進步。

　　為了維持檢查缺陷是積極的這樣一種理念，管理人員必須要承諾缺陷密度不會進入到性能報告之中。公開作出這種承諾是很有效的。這樣開發員就會知道他們要怎樣做，并抗議公開破壞這條規則的管理人員。

　　管理人員絕不應該將錯誤(bug)代碼作為消極性能評審的基礎。他們必須謹慎對待，并對批評造成的挫折感及消極反應保持敏感，并要一直提醒團隊發現錯誤(bug)是一件很好的事情。

　　9. 警惕老大哥效應(Big Brother Effect)

　　作為一個開發人員，您可以自動假設“老大哥正看著您呢”是真的，如果評審制度是由評審支持工具自動評價的，更是這樣的。您是否花費了很長的時間去評審一下更改?您的同行從您的代碼中是否發現了很多錯誤(bug)?這將如何影響您下一步的性能評價?

　　評估報表不應用來對付開發人員，尤其是在面對結對評審員時。這一做法會嚴重破壞道德觀。

　　制度對于流程評價來說非常重要，這反過來，又為流程改進提供了一個基礎。但是制度也可以被用來做壞事。如果開發人員相信制度是用來對付他們的，那么他們不光是對流程有敵意，而且他們的注意力可能轉到改變制度，而不是編寫更好的代碼，和變得更有效率上。

　　管理人員可以做很多事情，來解決這個問題。首先也是最重要的，他們必須要警惕這一點，并且必須確定代碼開發者沒有面臨很多的壓力，而“老大哥”問題必須每次都得到詳細的檢查。

　　制度應該用來評價流程的效率，或者流程更改的效果。記住，通常來說，最困難的代碼是由最有經驗的開發人員處理的。這些代碼，反過來，最有可能出問題，因此最難檢查，也有可能發現最多的缺陷。因此，大量的缺陷很有可能是由復雜性，以及代碼的分塊性造成的，而不是代碼開發者的能力造成的。

　　如果制度確實能夠幫助一個管理人員去發現一個問題，那么將某人踢出局可能會產生更多的問題。我們推薦管理人員在解決相關問題時，要將一個小組當做整體來對待。所以最好不要召開專門的會議，因為開發人員在解決特定的問題可能會有壓力。相反，您可以通過一個每周狀態會議，或者正常的程序來解決問題。

　　管理人員必須不斷地維持這樣一個年頭，即搜索缺陷是好的事情，而不是糟糕的，缺陷密度與開發員的能力并不是掛鉤的。記住對一個團隊來說，缺陷，尤其是團隊成員所引入缺陷的數量不應該被回避，也不應該用作能力的評價參數。

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

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

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

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

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

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

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

原文轉自：http://www.kjueaiud.com