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