11 個高效的同行代碼評審最佳實踐
使用 SmartBear CodeCollaborator 與 Rational Team Concert 進行輕量級代碼評審
Jason Cohen, CodeCollaborator 初始架構師, SmartBear Software
簡介： 這 11 項針對輕量級高效同行代碼評審最佳實踐被證明是有效的，它們建立在一個通過結合使用 IBM® Rational Team Concert™ 與 SmartBear CodeCollaborator 對 Cisco 系統的開發進行案例研究的基礎之上。它們可以幫助您確定評審既能夠改進您的代碼，又能利用好開發人員的時間。
本文的标簽: 11, best_practices, eclipse, process_management, 個高效的同行代碼評審最佳實踐, 代碼評審, 團隊開發, 應用開發, 品質保證, 軟體開發生命周期
标記本文！
釋出日期： 2011 年 5 月 04 日
級别： 中級
原創語言： 英文
通路情況 5125 次浏覽
建議： 0 (添加評論)
平均分 （共 6 個評分 ）
| 下載下傳試用版：IBM® Rational® Team Concert 标準版 | IBM® Rational® Team Concert 免費版 | ||||||
|---|---|---|---|---|---|---|
| 下載下傳更多的 IBM 軟體試用版，并加入 通路 developerWorks 社群上的 1. 一次評審量要低于 200–400 行代碼 Cisco 代碼評審研究（見于工具欄）顯示了為了得到優化的效率，開發員的評審量要低于一次 200-400 行代碼（LOC）。超過這個量，搜尋缺陷的能力就會降低。以這個速度，您可以找到 70-90% 的缺陷。換句話說，如果存在 10 個缺陷，那麼您可以找到其中的 7 到 9 個。 關于 Cisco 案例研究在 10 個月的監視工作之後，研究總結出了一個理論：如果适當操作的話，輕量級代碼評審工作與規範的評審工作同樣有效，但是前者的速度會更快（更省時）。與規範評審相比，輕量級代碼評審平均要少花 6.5 個小時，并發現更多的錯誤（bug）。 除了确認這些理論，研究中還發現了一些新的規律，本文将這些規律都概括了出來。 圖 1 中的圖，描述了缺陷密度與評審代碼行數量之間的關系，支援該規則。缺陷密度 就是每 1000 行代碼之中所發現的錯誤（bug）數。評審代碼行的數量超過 200 時，缺陷密度就會急劇地下降。 在這種情況下，缺陷密度就是“評審有效性”的評價手段。如果兩個評審員評審相同的代碼，其中一個發現了更多的錯誤（bug），那麼我們就會認為該評審員更有效率。圖 1 顯示了當我們将更多的代碼放到評審者面前時，她搜尋缺陷效率的變化情況。這種結果很合理，因為她可能不會花費大量的時間去評審，這樣就會不可避免的使得效率沒有以前高。 圖 1. 當代碼行數量超過 200 時缺陷密度就會急劇下降，400 以後缺陷密度幾乎為 0 回頁首 2. 每小時低于 300–500 LOC 檢查率的目标 定義
您要花點時間進行代碼評審。快速評審并不總是好的。我們的研究結果顯示檢查率低于“300-500 LOC/小時”時，可以得到優化的結果。根據所作的決定，評審者的檢查率有很大的變化，就算是相似的代碼開發者、評審者，檔案和評審規模，也存在巨大的差異。 為了找到優化的檢查率，我們将 缺陷密度 與評審者檢查代碼的 速度 進行了比較。得到的結果再一次落在了我們的預料之中：如果在評審您不花足夠的時間，那麼您就不會發現太多的缺陷。如果評審者面臨大量代碼的壓力，那麼他就不會每一行代碼投入相同的注意力。他不能研究同一位置處更改的所有版本。 是以，多快算是太快呢？圖 2 顯示了答案：伺服器端每小時超過 400 LOC 的評審速度會降低效率。而每小時 1000 LOC 的速度，您可能已經推出了，以這樣的速度評審員可能根本都沒有細看代碼。 圖 2. 評審量超過 500 行代碼時檢查效率就會下降了 回頁首 3. 花足夠的時間進行适當緩慢的評審，但是不要超過 60-90 分鐘
我們應該讨論，為了得到更好的結果，不應該過快地評價。但是您也不應該在一個位置花太多的時間。大約 60 分鐘後，評審者就會感到疲勞，于是就不會找到額外的缺陷了。這個結論得到了許多其他研究的支援。實際上，根據我們的常識，當人們從事注意力高度集中的活動時，性能狀态在 60-90 分鐘之後就會降低了。考慮到人體方面的限制，評審者在性能降低之前，不能評審超過 300–600 行的代碼。 但反過來說，評審代碼所花的時間不得低于五分鐘，就算代碼隻有一行也是如此。通常來說，單行的代碼也會影響到整個的系統，是以花上五分鐘時間去檢查更改可能造成的結果是值得的。 回頁首 4. 确定在評審開始之前代碼開發者已經注釋源代碼了 在評審開始之前代碼開發者可能就消除大多數的缺陷，這一點我們将會看到。如果我們需要開發員雙倍地檢查他們的工作，那麼評審可能更快地完成，而不用再去折中考慮代碼品質的問題。就我們所知，這種特定的想法尚未得到研究，是以我們在 Cisco 研究期間對其進行了測試。 圖 3. 代碼開發者準備對缺陷密度的震撼性效果 代碼開發者準備 說的是代碼開發者在評審之前要先注釋他們的源代碼。我們發明了這個術語，以描述研究中所評價的特定行為模式，大約 15% 的評審會阻止代碼開發者這樣做。注釋會指導評審者進行變更，顯示首先必須要檢視的檔案，并找到每一次代碼更改的原因。這些注釋不是代碼之中的評論，而隻是給其他評審者看的評論。 我們的理論就是，因為代碼開發者需要重新考慮，并解釋注釋過程中所發生的更改，是以代碼開發者需要在評審開始之前就找出許多缺陷，以讓評審變得更加有效。如此，評審過程将會産生低密度的缺陷，因為更少的錯誤（bug）剩餘了。很明顯，與沒有代碼開發者準備的評審相比，代碼開發者準備之後的評審有更少的缺陷存在。 我們還考慮過一個悲觀的理論，以解釋錯誤（bug）的低發現率。是不是當代碼開發者在作出一項評論時，評審者會有偏見，或者自鳴得意，這樣就不能盡可能多地發現錯誤（bug）了呢？我們随機抽查了 300 個評審者進行研究，結果證明評審者在評審代碼時确實非常小心，更少的錯誤（bug）被發現了。 回頁首 5. 為代碼評審建立可定量化的目标，并擷取制度，這樣您就可以改進流程了 有了項目，您就該決定代碼評審過程的目标，以及怎樣評價效率問題了。當您在定義特定的目标時，您就能夠決定同行評審是否真的達到了您所需要的結果。 最好從外部性的制度開始，例如“将支援通路降低 20%”或者“使開發引入的缺陷百分比減半”。這些資訊使您能夠更好地看清，從外部視角來看，代碼能夠做些什麼，您還需要一個可定量化的評價手段，而不是“修複更多錯誤（bug）”的模糊目标。 但是，在外部制度顯示結果之前需要花上一段時間。例如，支援性通路将不會得到影響，直到新的版本得到釋出并交到客戶手中為止。是以檢視内部性流程工具，以得到發現多少缺陷，缺陷就是問題所在，以及開發員在評審上所花時間的清晰結果。代碼評審的最常見内部性制度是 檢查率 ，缺陷率，以及 缺陷密度。 考慮一下隻有自動化或者緊密控制的流程，才能給您帶來可重複的代碼；人類并不擅長記住啟動或者終止計時器。為了得到最好的結果，您要使用能夠 自動 收集代碼的代碼評審工具，這樣用于流程改進的關鍵代碼就是精确的了。 為了改進和提高您的流程，您可以收集代碼并組合流程，以檢視更改是如何影響結果的。很快，您就将會知道什麼工作最适合您的團隊了。 回頁首 6. 使用檢查表，因為它能極大地影響代碼開發者和評審者的結果
我們極力推薦您使用檢查表，來确定您可能會忘記的事情，它對代碼開發者和評審者都有用。忽略是最難發現的缺陷；畢竟，評審不在那裡的東西是很困難的一件事。檢查表是解決這個問題的最好方式，因為它會提醒評審者和代碼開發者花點時間去考慮一下可能被遺忘的事情。檢查表還會提醒代碼開發者和評審者确定所有的錯誤（bug）都得到了處理，軟體功能已經通過了無效值測驗，而且已經建立了單元測試。 另外一個有用的概念就是 個人檢查表 。每個人一般都會犯 15-20 個錯誤（bug）。如果您注意到了一些典型的錯誤（bug），那麼您就可以開發自己的個人檢查表（Personal Software Process，Software Engineering Institute，以及 Capability Maturity Model Integrated 也都推薦該實踐方式）。評審者将會完成決定一般性錯誤（bug）的工作。您所應該做的，就是擁有一個簡短的檢查清單，一般都是您容易遺忘的事情。 一旦您開始在檢查清單中記錄自己的缺陷，那麼您就會少犯錯了。規則将不斷出現在您的腦海中，然後您的錯誤（bug）率就會下降了。這種情況我們将會發現它反複出現。 提示： 如果您想要得到關于檢查清單的更多具體資訊，那麼您可以得到本文代碼開發者所寫書籍的免費拷貝，這本書為 Best Kept Secrets of Peer Code Review，網址為 www.CodeReviewBook.com。 回頁首 7. 确認缺陷得到了修複 是的，這種“最佳實踐”看起來好像是沒有腦子的。如果您遇到了評審代碼以找到缺陷的所有問題，那麼修複它們就變得順理成章了！現在許多評審代碼的團隊沒有一種好的辦法，去追蹤評審期間找到的缺陷，并確定評審完成之前錯誤（bug）确實得到了修複。确認電子郵件之中的結果，或者實時評審是非常困難的。 記住這些錯誤（bug）通常不是在 Rational Team Concert 日志中輸入的，因為在代碼釋出給 QA 之前就發現了這些錯誤（bug）。是以，什麼是代碼在貼上“全部解決”标志之前确認缺陷的好辦法呢？我們建議使用好的協作性評審軟體，與 Rational Team Concert 相內建，以追蹤評審之中所發現的缺陷。有了正确的工具，評審員就可以記錄錯誤（bug），并在必要時與代碼開發者進行讨論了。然後代碼開發者會修複問題，并通知評審者，而評審者必須确認每個問題都得到了解決。工具應該追蹤評審期間所發現的問題，并確定直到所有的錯誤（bug）被評審者 修複 才完成評審（或者作為稍後解決的單獨工作項追蹤）。工作項隻有在評審完成時才能通過。
既然您已經學會了代碼評審 流程 的最佳實踐方式，那麼我們接下來将會讨論一些社會效應，以及怎樣管理它們以獲得最佳的結果。 回頁首 8. 培養良好的代碼評審文化氛圍，在這樣的氛圍中可以積極地評審缺陷 與其他我們能看到的大多數技術相比，代碼評審對于真實團隊建構能夠發揮更大的作用，但是隻是在管理人員能夠以一種積極的，向上的，有技巧的方式進行交流時，這種優勢才能發揮出來。将缺陷看做是不好的事物很容易（畢竟，它們是代碼之中的錯誤（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. 采用輕量級，工具支援的代碼評審 代碼評審一般有些主要的類型和無數的變數，而指南卻能适用它們中的任何一個。但是，為了完全優化團隊花在評審之上的時間，我們要使用工具支援的輕量級評審過程來得到最優的結果。搜尋缺席時，它是有效的，實用的。 規範，或者 重量級的 檢查已經流行了 30 年。它已經不是評審代碼的有效形式了。重量級檢查平均花費的時間是每 200 行代碼 9 個小時。盡管它很有效，但是嚴格的過程需要三到六個參與者，并進行一系列繁瑣的會議以讨論具體的細節。不幸的是，盡管需要繁瑣的過程，但是大多數的公司沒有條件将程式設計人員內建起來,進行長時間的會議。最近的幾年，許多開發公司已經完全放棄了會議安排，紙質代碼閱讀，以及繁瑣的作品收集工作，轉而采用新型 輕量級 過程，以從規範的會議及老式重量級過程的重壓中解放起來。 我們使用在 Cisco 中的案例研究，來确定輕量級技術與規範過程比較的特點。結果顯示輕量級代碼評審所需要的時間隻是規範評審的五分之一（甚至更少），而且前者能夠發現更多的錯誤（bug）。 盡管輕量級代碼評審擁有很多的方法，例如實時評審和電子郵件評審，但是最有效的評審方法還是使用協作性的軟體工具來促進評審，這些軟體工具例如 SmartBear 的 CodeCollaborator（見于圖 4）。 圖 4. Cisco 研究中所使用到的輕量級代碼評審工具，CodeCollaborator 圖 4 的大圖 CodeCollaborator 是與 IBM® Rational Team Concert 工作流程相內建的唯一代碼評審工具。它将源代碼評審與聊天形式的協作內建起來，進而使開發員從聯系注釋與私人代碼行的繁瑣活動中解放了出來。當程式員向工作項添加更改項進行評審時，在 CodeCollaborator 中将會自動建立評審，并配置設定适當的準許者。團隊成員可以直接注釋代碼，與代碼開發者聊天，并就每一個問題進行協作，追蹤錯誤（bug）并修複缺陷。整個過程不需要會議，列印，或者安排日程。 有了基于 Rational Team Concert 與 CodeCollaborator 的輕量級評審過程，團隊就可以進行更有效的評審，并實作代碼評審的有利點。
到現在為止，您已經被經實踐證明有效的經驗從頭到尾武裝起來了，以確定從過程和社會的角度來看，團隊在代碼評審過程之中能夠節省大量的時間。當然，您必須确實 完成了 代碼評審，以實作這些便利。對 100% 的代碼使用評審的規範方法（有人對這個百分比存在異議，簡單來說是不現實的。內建到 Rational Team Concert 環境之中的工具支援輕量級代碼評審，提供了最強大的功能，因為它提供了一個有效的方法去搜尋缺陷，而且不會涉及到開發員頭痛的一些問題。有了正确的工具和這些實踐方式，您的團隊就可以對所有的代碼進行同行評審，并在軟體達到 QA 階段之前就找到成本極高的錯誤（bug），這樣您的客戶每次都能夠得到頂級品質的産品了。 為了友善您檢視，下面總結了在一個簡單清單中最容易保持的 11 項實踐方式：
參考資料 學習
Jason Cohen 是 CodeCollaborator 的初始架構師和 SmartBear Software 的建立人。在他的公司被收購之後，他繼續參與許多新的 SmartBear 軟體的戰略發起人，并且經常進行有關同行代碼評審收益的演講。他也是其它三個公司的建立人，包括 WPEngine 和 ITWatchDogs。更多有關 SmartBear Software 的資訊，請通路 www.smartbear.com。 版權聲明：本文為CSDN部落客「igorzhang」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。 原文連結：https://blog.csdn.net/igorzhang/article/details/7608691 更多相關推薦11 個高效的同行代碼評審最佳實踐(轉載)雜項 ibm 工具 cisco 工作 靈活開發 産品 11個高效的同行代碼評審最佳實踐使用SmartBearCodeCollaborator與RationalTeamConcert進行輕量級代碼評審JasonCohen,CodeCollaborator初始架構師,SmartBearSoftware簡介： 這11項針對輕量級高效同行代碼評審最佳實踐... 11個高曉的同行代碼審查項目管理 審查 cisco 工作 工具 ibm 優化 簡介： 這11項針對輕量級高效同行代碼評審最佳實踐被證明是有效的，它們建立在一個通過結合使用IBM®RationalTeamConcert™與SmartBearCodeCollaborator對Cisco系統的開發進行案例研究的基礎之上。它們可以幫助您確定.... 同行評審的5個要點項目管理 語言 活動 工作 産品 測試 筆者所知道的所有軟體公司，無論規模大小，都正式或者非正式的進行了同行評審。但是對于同行評審，并非每個公司都取得了期望的成果，這種現象的存在很大一部分的原因在于很多公司隻明白了同行評審的操作方式而對其背... 11個高效的同行代碼審查最佳實踐UML和架構設計 簡介：這11項針對輕量級高效同行代碼評審最佳實踐被證明是有效的，它們建立在一個通過結合使用IBM®RationalTeamConcert™與SmartBearCodeCollaborator對Cisco系統的開發進行案例研究的基礎之上。它們可以幫助您確定評... CMMI v2.0之二 同行評審項目管理 靈活 CMMI 今早一金融行業企業CMMI啟動會上，發起人（公司上司）對如何提升傳遞品質時，便提到過去項目大部分過程中的缺陷大部分都是後期，例如系統測試時發現，很多需求/設計階段的缺陷未在本階段被發現。他希望大家加強前期....
猜您喜歡
文章随機推薦
|