原創(chuàng)2014-01-08小艾老師

PMP 認證是由美國項目管理協(xié)會（PMI）發(fā)起的，嚴格評估項目管理人員知識技能是否具有高品質的資格認證考試。PMP 認證在全球206個國家和地區(qū)得到了廣泛的認可，是項目管理領域含金量最高的認證。

中文名PMP項目管理認證
英文名Project Management Professional
英文簡稱PMP
頒證機構PMI（美國項目管理協(xié)會）
證書類別項目管理，PM
同類認證PRINCE2、國家軟考（中項/高項）

PMP分享有效的Code Review實踐經驗

發(fā)布時間：2014.01.08

緯創(chuàng)軟件：李安，資深PM

什么是Code Review？

Code Review代碼評審是指在軟件開發(fā)過程中，通過對源代碼進行系統(tǒng)性檢查的過程。通常的目的是查找各種缺陷，包括代碼缺陷、功能實現問題、編碼合理性、性能優(yōu)化等；_軟件總體質量和提高開發(fā)者自身水平。 Code Review是輕量級代碼評審，相對于正式代碼評審，輕量級代碼評審所需要的各種成本要明顯低得多，如果流程正確，它可以起到更加積極的效果。正因如此，輕量級代碼評審經常性地被引入到軟件開發(fā)過程中。

為什么Code Review？

1.提高代碼質量。
2.及早發(fā)現潛在缺陷，降低修改/彌補缺陷的成本。
3.促進團隊內部知識共享，提高團隊整體水平。
4.評審過程對于評審人員來說，也是一種思路重構的過程。幫助更多的人理解系統(tǒng)。
5.是一個傳遞知識的手段，可以讓其它并不熟悉代碼的人知道作者的意圖和想法，從而可以在以后輕松維護代碼。
6.鼓勵程序員們相互學習對方的長處和優(yōu)點。
7.可以被用來確認自己的設計和實現是一個清楚和簡單的。

如何做Code Review？

Code Review檢查什么？

1.結構問題
      代碼_大的問題，不是一兩個地方有技術缺陷，也不是業(yè)務邏輯錯誤，而是整個軟件設計的不好。前兩者更容易通過測試或使用來發(fā)現和更正，但后者就不同了。如果回想一下自己見過的各種爛攤子，是不是有同感？具體哪里有問題怎么改說不上來，就是整個軟件看上去混亂無章，無從下手。
      具體結構問題包括：重復拷貝代碼（不封裝函數，不用Template/泛型……），函數過長（超過一屏幕就叫過長），錯誤封裝（不恰當的public/不用Interface/不內聚/強耦合/在類中封裝了無關方法……），內容錯誤（多個無關類置于一個文件/不恰當的命名……）等等。
      改正結構問題，是從編寫可靠軟件向編寫精美軟件邁進的重要方法。
2.業(yè)務邏輯問題
      就是軟件是否與需求的要求符合的問題。審核者和被審核者經常對業(yè)務需求的理解有差異，借此機會同步一下，必要時引入PO（產品經理/產品負責人）。
      有人會說業(yè)務邏輯問題不是一測試就知道了嗎？可是測試一般發(fā)生在很久以后，有些邏輯測試還需要一定的觸發(fā)條件，而且測試只會發(fā)現失效（failure, 與預期不符）而不能發(fā)現缺陷（defect, 具體哪里出了錯），等積累長了，誰也找不到原因了。
3.編程素養(yǎng)問題
      很多問題屬于那種“這樣也行那樣也行”的狀態(tài)，比如命名/初始值/縮進/斷行……但是高手的做法總是比新手好一些。
      比如bool result = true; 這句話就有問題，剛初始化就先宣布成功，必有隱患。這是一個真實案例，而下面也的確有一個分支錯誤地返回了這個true（實際案例是個HRESULT）。而發(fā)現這個問題，不是測試而是代碼檢查。實際上測試幾乎發(fā)現不了這些問題，比如上面那段代碼會在某文件打不開的時候錯誤地返回這個true，而在測試中幾乎不會故事破壞那個文件來測試其結果。

經常進行Code Review

常見的Code Review是高手審核新手，或者師傅走查徒弟。一般而言，大致高手每天能編寫100多行有效代碼（按分號計數），新手會多一些但也不超過200（他們編寫代碼比較費），也就是10個屏幕以內。有經驗的人一定知道：高手看新手的代碼，5秒鐘就能發(fā)現問題。所以不用花上很長時間去做Code Review，而應該“少吃多餐”，每次可以5分鐘，10分鐘，每天2-3次甚至更多。看到一個問題就要徹底解決，不需要一次檢查很多，問題一次比一次少即可。
但是切記不可積累，隔很長時間才去做Code Review，你就會面臨那近萬行的代碼，以前N多摻和在一起的功能，你會發(fā)現，整個Code Review變得非常地艱難，用不了一會兒，你就會發(fā)現你會疲憊地打著哈欠，但還是要堅持，有時候，這樣的Review會持續(xù)N個小時以上，相當的夸張。而且會出現相當多的問題和爭論，因為，這就好像，人家都把整個房子蓋好了，大家Review時這挑一點那挑一點，有時候觸動地基或是承重墻體，需要大動手術，讓人返工，這當然會讓蓋房的人一下就跳起來極力地維護自己的代碼，_后還傷了他人的感情。

我們怎么做 Code Review

我?guī)н^的項目中，做Code Review這方面大多感覺比較凌亂，也沒有什么統(tǒng)一的做法。不過從形式上來看大體可以分為兩大類：一類是TM技術經理對項目中成員Team一個一個的做Code Review，或者是團隊資深人員來做（姑且就叫個人式吧）。一類是做Code Review Meeting，以會議形式來做Code Review（姑且叫會議式）。
個人式

對于個人式，其實在上面“如何做Code Review”的話題中已經談到了很多了。包括我們要及時的不定期的每時每刻的去做Code Review，包括我們要按照結構問題，業(yè)務邏輯問題，編程素養(yǎng)問題逐一去檢查Code等等。很多項目我們也都做了，甚至是都做到了。只是還有不夠好的地方，需要深入的地方。具體的方法上面已經講了，后面我會具體講講如何量化和跟蹤。而對于PM來說，如何監(jiān)控Code Review這件事就顯得非常重要。

會議式

會議式，真正的會議式去做代碼評審，如果做到位了效果應該是_好的，_理想的情況是一堆專家（包括技術專家甚至還有業(yè)務專家、測試專家等），拿著代碼一行一行的去Review。但是這種做法的成本也非常之高，不管是時間成本也好，還是費用成本都相當的昂貴，一般只有在大型_項目才會使用，比如航天航空的項目，做Code Review之后的缺陷率是相當的低的。我們是怎么做Code Review Meeting的呢？首先我們會在開會之前，選出典型的案例或者問題一起拿到會上去討論，多半是分享一些經驗和強調一些容易犯錯的地方。一般一次會議不會超過2個小時，每周一次會議即可。這樣會議的效果比較好，成本也相對較低。因為由于Team中成員的“素質”參差不齊，所以一起去做代碼評審確實效果很差。

我對 Code Review 的一點思考

       作為PM我，對Code Review的思考是，我應該如何管理好Code Review？也就是說假設我把Code Review當做一個項目來看，怎樣做好這個項目呢？
       其實很簡單，首先我要有一個正確的、真實的、可執(zhí)行的計劃，然后能在實施Code Review時給予TM或評審人一定的指導，再然后跟蹤偏差，分析原因，變更計劃。
       那麼如何做計劃？而且要是正確的、真實的、可執(zhí)行的。這里我們需要結合一下Project Quality Plan了。可能有的童鞋還不知道，我簡單解釋一下Project Quality Plan，Project Quality Plan是一個項目質量計劃，主要內容有項目交付物以及交付要求，計劃達到怎么樣的質量目標，要采取怎么樣的過程方法，Quality Breakdown各個階段的質量目標分解等等。通過詳細的質量目標分解我們就可以預測各個階段預計產生的缺陷數是多少。此時我們PM就要思考，有了各個階段的缺陷數量，我們是不是可以分解一下，那么我們做Code Review的目標是要發(fā)現多少缺陷呢？舉個例子：假設我們代碼的規(guī)模是100k行，我們目前團隊產生缺陷數的基線大概是12~15 (Bugs/Kloc)，Code Review需要找出8~10 (Bugs/Kloc)，也就是100*8~10=800~1000。這樣一來我們總數就有了，也就是說對于100k代碼行這種規(guī)模的項目我們Code Review總共要找到800~1000個缺陷才算達到了比較好的效果。當然如果做到這里還遠遠不夠，我們還要對這個目標進行細化的分解。要分解到模塊，分解到人（如果多人Review的話）。分解到模塊很好理解，我們把整個系統(tǒng)分解為幾個大的模塊，或者模塊集（相關性大的可以放一起）。然后分析模塊的難易度，以及模塊將來可能的負責人，然后評估每類模塊我們應該找到多少缺陷。可能對于業(yè)務復雜或者算法復雜或者負責人水平較低的模塊我們需要更多的時間去Review并產出更多的缺陷，反之則少。如下圖：

模塊	規(guī)模	復雜度	PIC	缺陷分布	（計算）	（調整系數）
1	20k	高	中	240~288	20*12	1.2
2	20k	中	中	180	20*9	1
3	20k	中	中	180	20*9	1
4	20k	中	弱	180~198	20*9	1.1
5	20k	低	弱	120	20*6	1

      有了具體的計劃Code Review的時候也就有了指導和參考目標。在執(zhí)行的時候我們也就可以規(guī)劃出人合理的力投入分配。做起來相對來說就比較容易了。
      _后就是跟蹤、偏差分析與變更了，當發(fā)現我們與實際計劃又嚴重偏差我們要分析原因，然后做計劃變更。比如發(fā)現偏差時，我們可以用根因分析，人、機、料、法、環(huán)、測。我們哪里做的不夠好，如果可以解決，找出主要原因立刻解決即可。如果發(fā)現是計劃有問題就去變更計劃好了。這里就不討論具體方法了。方法有很多，只要適合自己的項目即可。
      其實Code Review的方法還有很多，比如結對編程也是一種很好的形式，特別適合敏捷XP團隊，但是因為目前我也沒有很好的實踐，所以也就沒有寫到。
      _后希望我寫的對大家能有一點點的幫助。也歡迎對Code Review有自己見解的朋友能和我一起來探討這個話題。并歡迎指正我不對的地方。Thanks

【艾威（中國）】簡介：

　　艾威（AVTECH）總部設在美國NEW JERSEY，是北美排行_的專業(yè)培訓機構,設有4大分校，數十個培訓點遍布北美、西歐和東亞;2000年進入中國，以培養(yǎng)國際化的中高端信息人才為己任,專注于國際前沿的新技術研發(fā)與信息科技新興行業(yè)的開拓教育。

　　艾威培訓（Avtech Institute of Technology)，源于美國，始于1998；是北美著名的培訓機構，公司總部位于美國新澤西州，2000年進入中國，以培養(yǎng)國際化的中高端信息人才為己任,專注于國際前沿的新技術研發(fā)新興行業(yè)的開拓教育,艾威主要的服務為培訓與咨詢兩大類，目前培訓的主要產品有：項目管理培訓、IT管理培訓、IT技術培訓、云計算大數據培訓、需求管理培訓、產品管理培訓，信息安全類，AI人工智能等....近十類上幾百門的課程的培訓與咨詢服務。
　　艾威進入中國這十八年來已經服務了超過5000多家客戶，獲得了良好的口碑！也成為了眾多500強企業(yè)指定的培訓服務供應商.
　　● 艾威培訓(Avtech Institute of Technology)，源于美國，始于1998.
　　● 艾威培訓(Avtech Institute of Technology)是Prometric，VUE，PSI等眾多國際認證中心授權的考點

　　● 2003年成為國際項目管理協(xié)會PMI授權的全球(PMP,PGMP,ACP,PBA)教育機構

　　● 2008年成為國際需求管理協(xié)會IIBA授權的全球(CCBA,CBAP)教育機構

　　● 2012年成為IT服務管理官方EXIN授權的ITIL，ITIL EXPERT,Prince2,EXIN Agile Scrum Master教育機構

　　● 2016年成為國際信息審計協(xié)會ISACA授權的CISA,CISM,CRISC,CGEIT,COBIT教育機構

　　● 2017年成為The Open Group授權的TOGAF企業(yè)架構的官方培訓機構。
　　● 2017年成為EPI 授權的數據中心CDCP培訓機構，華東地區(qū)_CDCP授權培訓機構，同時也是CDCP認證考試考場。
　　● 2017年成為國際外包專業(yè)協(xié)會(IAOP)_授權外包治理國際認證SGF(Sourcing GovernanceFoundation)。

本文來自于艾威培訓

轉載請注明：http://m.c-d21.com/news/592.html

上一篇：PMP隨想：教練技術對PM的價值

下一篇：精心耕作，用心探索--PMO項目管理主題實踐小記

贊