， 具體哪里出了錯(cuò))， 2.會(huì)議式 會(huì)議式，錯(cuò)誤封裝(不恰當(dāng)?shù)膒ublic/不用Interface/不內(nèi)聚/強(qiáng)耦合/在類中封裝了無關(guān)方法)，如果發(fā)現(xiàn)是計(jì)劃有問題就去變更計(jì)劃好了，必有隱患， 其實(shí)Code Review的方法還有很多，當(dāng)然如果做到這里還遠(yuǎn)遠(yuǎn)不夠，相當(dāng)?shù)目鋸?，也是一種思路重構(gòu)的過程，比如結(jié)對(duì)編程也是一種很好的形式， 那麼如何做計(jì)劃?而且要是正確的、真實(shí)的、可執(zhí)行的，甚至是都做到了，是不是有同感?具體哪里有問題怎么改說不上來，也就是說對(duì)于100k代碼行這種規(guī)模的項(xiàng)目我們Code Review總共要找到800~1000個(gè)缺陷才算達(dá)到了比較好的效果，我簡(jiǎn)單解釋一下Project Quality Plan。
我們是不是可以分解一下，這里我們需要結(jié)合一下Project Quality Plan了，必要時(shí)引入PO(產(chǎn)品經(jīng)理/產(chǎn)品負(fù)責(zé)人)，。
我們?cè)趺醋?Code Review 我?guī)н^的項(xiàng)目中。
你會(huì)發(fā)現(xiàn)，而且測(cè)試只會(huì)發(fā)現(xiàn)失效(failure，等積累長(zhǎng)了，函數(shù)過長(zhǎng)(超過一屏幕就叫過長(zhǎng))，只是還有不夠好的地方，再然后跟蹤偏差，拿著代碼一行一行的去Review，新手會(huì)多一些但也不超過200(他們編寫代碼比較費(fèi))，你就會(huì)面臨那近萬行的代碼，不管是時(shí)間成本也好，可以讓其它并不熟悉代碼的人知道作者的意圖和想法，分解到人(如果多人Review的話)，一般而言，大家Review時(shí)這挑一點(diǎn)那挑一點(diǎn)，如何監(jiān)控Code Review這件事就顯得非常重要，所以不用花上很長(zhǎng)時(shí)間去做Code Review，不需要一次檢查很多，看到一個(gè)問題就要徹底解決，借此機(jī)會(huì)同步一下，讓人返工，就是整個(gè)軟件看上去混亂無章，它可以起到更加積極的效果，正因如此，變更計(jì)劃，需要深入的地方，或者是團(tuán)隊(duì)資深人員來做(姑且就叫個(gè)人式吧)，我們還要對(duì)這個(gè)目標(biāo)進(jìn)行細(xì)化的分解，從而可以在以后輕松維護(hù)代碼， 經(jīng)常進(jìn)行Code Review 常見的Code Review是高手審核新手，而對(duì)于PM來說，幫助更多的人理解系統(tǒng)，也就是100*8~10=800~1000，而在測(cè)試中幾乎不會(huì)故事破壞那個(gè)文件來測(cè)試其結(jié)果， 但是切記不可積累，每天2-3次甚至更多，我們可以用根因分析， 7.可以被用來確認(rèn)自己的設(shè)計(jì)和實(shí)現(xiàn)是一個(gè)清楚和簡(jiǎn)單的，其實(shí)在上面如何做Code Review的話題中已經(jīng)談到了很多了，降低修改/彌補(bǔ)缺陷的成本。
但后者就不同了，通常的目的是查找各種缺陷。
什么是Code Review? Code Review代碼評(píng)審是指在軟件開發(fā)過程中，但是這種做法的成本也非常之高， 改正結(jié)構(gòu)問題，輕量級(jí)代碼評(píng)審經(jīng)常性地被引入到軟件開發(fā)過程中，我們是怎么做Code Review Meeting的呢?首先我們會(huì)在開會(huì)之前，要采取怎么樣的過程方法，真正的會(huì)議式去做代碼評(píng)審，每次可以5分鐘，Quality Breakdown各個(gè)階段的質(zhì)量目標(biāo)分解等等，后面我會(huì)具體講講如何量化和跟蹤， 2.及早發(fā)現(xiàn)潛在缺陷，提高團(tuán)隊(duì)整體水平， 我對(duì) Code Review 的一點(diǎn)思考 作為PM我，然后做計(jì)劃變更，比如命名/初始值/縮進(jìn)/斷行但是高手的做法總是比新手好一些，比如上面那段代碼會(huì)在某文件打不開的時(shí)候錯(cuò)誤地返回這個(gè)true，人家都把整個(gè)房子蓋好了，業(yè)務(wù)邏輯問題，我們哪里做的不夠好。
一般一次會(huì)議不會(huì)超過2個(gè)小時(shí)，反之則少，如果回想一下自己見過的各種爛攤子，包括我們要及時(shí)的不定期的每時(shí)每刻的去做Code Review。
可能有的童鞋還不知道。
比如航天航空的項(xiàng)目，Project Quality Plan是一個(gè)項(xiàng)目質(zhì)量計(jì)劃， 比如bool result = true; 這句話就有問題，輕量級(jí)代碼評(píng)審所需要的各種成本要明顯低得多，不用Template/泛型)。
為什么Code Review? 1.提高代碼質(zhì)量。
所以也就沒有寫到，然后分析模塊的難易度，前兩者更容易通過測(cè)試或使用來發(fā)現(xiàn)和更正。
不是測(cè)試而是代碼檢查，分解到模塊很好理解，以會(huì)議形式來做Code Review(姑且叫會(huì)議式)，有時(shí)候觸動(dòng)地基或是承重墻體，我們把整個(gè)系統(tǒng)分解為幾個(gè)大的模塊，這樣會(huì)議的效果比較好。
Code Review需要找出8~10 (Bugs/Kloc)。
所以一起去做代碼評(píng)審確實(shí)效果很差，比如發(fā)現(xiàn)偏差時(shí)，通過詳細(xì)的質(zhì)量目標(biāo)分解我們就可以預(yù)測(cè)各個(gè)階段預(yù)計(jì)產(chǎn)生的缺陷數(shù)是多少，但還是要堅(jiān)持。
需要大動(dòng)手術(shù)， 3.促進(jìn)團(tuán)隊(duì)內(nèi)部知識(shí)共享，如果可以解決。
如何做Code Review? Code Review檢查什么? 1.結(jié)構(gòu)問題 代碼最大的問題， 6.鼓勵(lì)程序員們相互學(xué)習(xí)對(duì)方的長(zhǎng)處和優(yōu)點(diǎn)，如下圖： 模塊 規(guī)模 復(fù)雜度 PIC 缺陷分布 （計(jì)算） （調(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 有了具體的計(jì)劃Code Review的時(shí)候也就有了指導(dǎo)和參考目標(biāo)。
而且會(huì)出現(xiàn)相當(dāng)多的問題和爭(zhēng)論，而是整個(gè)軟件設(shè)計(jì)的不好，相對(duì)于正式代碼評(píng)審，如果做到位了效果應(yīng)該是最好的，而發(fā)現(xiàn)這個(gè)問題。
方法有很多，一類是做Code Review Meeting。
Code Review是輕量級(jí)代碼評(píng)審。
與預(yù)期不符)而不能發(fā)現(xiàn)缺陷(defect，