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

PMP項目管理認(rèn)證知識體系考證須知證書含金量培訓(xùn)大綱 3分鐘小視頻我要提問

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

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

PMP分享有效的Code Review實踐經(jīng)驗

發(fā)布時間：2014.01.08

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

什么是Code Review？

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

為什么Code Review？

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

如何做Code Review？

Code Review檢查什么？

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

經(jīng)常進行Code Review

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

我們怎么做 Code Review

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

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

會議式

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

我對 Code Review 的一點思考

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

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

【艾威（中國）】簡介：

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

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

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

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

　　● 2012年成為IT服務(wù)管理官方EXIN授權(quán)的ITIL，ITIL EXPERT,Prince2,EXIN Agile Scrum Master教育機構(gòu)

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

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

本文來自于艾威培訓(xùn)

轉(zhuǎn)載請注明：http://m.guidepoststore.com/news/592.html

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

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

贊