如何有效的进行Code Review

， 具体哪里出了错)， 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，