日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

Code Review如何有效的進行( 二 )

云知道


但是切記不可積累，隔很長時間才去做Code Review，你就會面臨那近萬行的代碼，以前N多摻和在一起的功能，你會發(fā)現(xiàn)，整個Code Review變得非常地艱難，用不了一會兒，你就會發(fā)現(xiàn)你會疲憊地打著哈欠，但還是要堅持，有時候，這樣的Review會持續(xù)N個小時以上，相當?shù)目鋸?。而且會出現(xiàn)相當多的問題和爭論，因為，這就好像，人家都把整個房子蓋好了，大家Review時這挑一點那挑一點，有時候觸動地基或是承重墻體，需要大動手術(shù)，讓人返工，這當然會讓蓋房的人一下就跳起來極力地維護自己的代碼，最后還傷了他人的感情 。
我們怎么做 Code Review
我?guī)н^的項目中，做Code Review這方面大多感覺比較凌亂，也沒有什么統(tǒng)一的做法 。不過從形式上來看大體可以分為兩大類：一類是TM技術(shù)經(jīng)理對項目中成員Team一個一個的做Code Review，或者是團隊資深人員來做(姑且就叫個人式吧) 。一類是做Code Review Meeting，以會議形式來做Code Review(姑且叫會議式) 。
1.個人式
對于個人式，其實在上面“如何做Code Review”的話題中已經(jīng)談到了很多了 。包括我們要及時的不定期的每時每刻的去做Code Review，包括我們要按照結(jié)構(gòu)問題，業(yè)務(wù)邏輯問題，編程素養(yǎng)問題逐一去檢查Code等等 。很多項目我們也都做了，甚至是都做到了 。只是還有不夠好的地方，需要深入的地方 。具體的方法上面已經(jīng)講了，后面我會具體講講如何量化和跟蹤 。而對于PM來說，如何監(jiān)控Code Review這件事就顯得非常重要 。
2.會議式
會議式，真正的會議式去做代碼評審，如果做到位了效果應(yīng)該是較好的，最理想的情況是一堆專家(包括技術(shù)專家甚至還有業(yè)務(wù)專家、測試專家等)，拿著代碼一行一行的去Review 。但是這種做法的成本也非常之高，不管是時間成本也好，還是費用成本都相當?shù)陌嘿F，一般只有在大型尖端項目才會使用，比如航天航空的項目，做Code Review之后的缺陷率是相當?shù)牡偷?。我們是怎么做Code Review Meeting的呢?首先我們會在開會之前，選出典型的案例或者問題一起拿到會上去討論，多半是分享一些經(jīng)驗和強調(diào)一些容易犯錯的地方 。一般一次會議不會超過2個小時，每周一次會議即可 。這樣會議的效果比較好，成本也相對較低 。因為由于Team中成員的“素質(zhì)”參差不齊，所以一起去做代碼評審確實效果很差 。
我對 Code Review 的一點思考
作為PM我，對Code Review的思考是，我應(yīng)該如何管理好Code Review?也就是說假設(shè)我把Code Review當做一個項目來看，怎樣做好這個項目呢?
其實很簡單，首先我要有一個正確的、真實的、可執(zhí)行的計劃，然后能在實施Code Review時給予TM或評審人一定的指導(dǎo)，再然后跟蹤偏差，分析原因，變更計劃 。
那如何做?而且要是正確的、真實的、可執(zhí)行的 。這里我們需要結(jié)合一下Project Quality Plan了 ?？赡苡械耐€不知道，我簡單解釋一下Project Quality Plan，Project Quality Plan是一個項目質(zhì)量計劃，主要內(nèi)容有項目交付物以及交付要求，計劃達到怎么樣的質(zhì)量目標，要采取怎么樣的過程方法，Quality Breakdown各個階段的質(zhì)量目標分解等等 。通過詳細的質(zhì)量目標分解我們就可以預(yù)測各個階段預(yù)計產(chǎn)生的缺陷數(shù)是多少 。此時我們PM就要思考，有了各個階段的缺陷數(shù)量，我們是不是可以分解一下，那么我們做Code Review的目標是要發(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個缺陷才算達到了比較好的效果 。當然如果做到這里還遠遠不夠，我們還要對這個目標進行細化的分解 。要分解到模塊，分解到人(如果多人Review的話) 。分解到模塊很好理解，我們把整個系統(tǒng)分解為幾個大的模塊，或者模塊集(相關(guān)性大的可以放一起) 。然后分析模塊的難易度，以及模塊將來可能的負責人，然后評估每類模塊我們應(yīng)該找到多少缺陷 。可能對于業(yè)務(wù)復(fù)雜或者算法復(fù)雜或者負責人水平較低的模塊我們需要更多的時間去Review并產(chǎn)出更多的缺陷，反之則少 。如下圖：

推薦閱讀