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