但是切记不可积累，隔很长时间才去做Code Review，你就会面临那近万行的代码，以前N多掺和在一起的功能，你会发现，整个Code Review变得非常地艰难，用不了一会儿，你就会发现你会疲惫地打着哈欠，但还是要坚持，有时候，这样的Review会持续N个小时以上，相当的夸张 。而且会出现相当多的问题和争论，因为，这就好像，人家都把整个房子盖好了，大家Review时这挑一点那挑一点，有时候触动地基或是承重墙体，需要大动手术，让人返工，这当然会让盖房的人一下就跳起来极力地维护自己的代码，最后还伤了他人的感情 。
我们怎么做 Code Review
我带过的项目中，做Code Review这方面大多感觉比较凌乱，也没有什么统一的做法 。不过从形式上来看大体可以分为两大类：一类是TM技术经理对项目中成员Team一个一个的做Code Review，或者是团队资深人员来做(姑且就叫个人式吧) 。一类是做Code Review Meeting，以会议形式来做Code Review(姑且叫会议式) 。
1.个人式
对于个人式，其实在上面“如何做Code Review”的话题中已经谈到了很多了 。包括我们要及时的不定期的每时每刻的去做Code Review，包括我们要按照结构问题，业务逻辑问题，编程素养问题逐一去检查Code等等 。很多项目我们也都做了，甚至是都做到了 。只是还有不够好的地方，需要深入的地方 。具体的方法上面已经讲了，后面我会具体讲讲如何量化和跟踪 。而对于PM来说，如何监控Code Review这件事就显得非常重要 。
2.会议式
会议式，真正的会议式去做代码评审，如果做到位了效果应该是较好的，最理想的情况是一堆专家(包括技术专家甚至还有业务专家、测试专家等)，拿着代码一行一行的去Review 。但是这种做法的成本也非常之高，不管是时间成本也好，还是费用成本都相当的昂贵，一般只有在大型尖端项目才会使用，比如航天航空的项目，做Code Review之后的缺陷率是相当的低的 。我们是怎么做Code Review Meeting的呢?首先我们会在开会之前，选出典型的案例或者问题一起拿到会上去讨论，多半是分享一些经验和强调一些容易犯错的地方 。一般一次会议不会超过2个小时，每周一次会议即可 。这样会议的效果比较好，成本也相对较低 。因为由于Team中成员的“素质”参差不齐，所以一起去做代码评审确实效果很差 。
我对 Code Review 的一点思考
作为PM我，对Code Review的思考是，我应该如何管理好Code Review?也就是说假设我把Code Review当做一个项目来看，怎样做好这个项目呢?
其实很简单，首先我要有一个正确的、真实的、可执行的计划，然后能在实施Code Review时给予TM或评审人一定的指导，再然后跟踪偏差，分析原因，变更计划 。
那如何做?而且要是正确的、真实的、可执行的 。这里我们需要结合一下Project Quality Plan了 。可能有的童鞋还不知道，我简单解释一下Project Quality Plan，Project Quality Plan是一个项目质量计划，主要内容有项目交付物以及交付要求，计划达到怎么样的质量目标，要采取怎么样的过程方法，Quality Breakdown各个阶段的质量目标分解等等 。通过详细的质量目标分解我们就可以预测各个阶段预计产生的缺陷数是多少 。此时我们PM就要思考，有了各个阶段的缺陷数量，我们是不是可以分解一下，那么我们做Code Review的目标是要发现多少缺陷呢?举个例子：假设我们代码的规模是100k行，我们目前团队产生缺陷数的基线大概是12~15 (Bugs/Kloc)，Code Review需要找出8~10 (Bugs/Kloc)，也就是100*8~10=800~1000 。这样一来我们总数就有了，也就是说对于100k代码行这种规模的项目我们Code Review总共要找到800~1000个缺陷才算达到了比较好的效果 。当然如果做到这里还远远不够，我们还要对这个目标进行细化的分解 。要分解到模块，分解到人(如果多人Review的话) 。分解到模块很好理解，我们把整个系统分解为几个大的模块，或者模块集(相关性大的可以放一起) 。然后分析模块的难易度，以及模块将来可能的负责人，然后评估每类模块我们应该找到多少缺陷 。可能对于业务复杂或者算法复杂或者负责人水平较低的模块我们需要更多的时间去Review并产出更多的缺陷，反之则少 。如下图：
推荐阅读
- 荣耀手机如何隐藏应用程序
- 8p如何强制重启
- 医保电子凭证如何获取
- 电动自行车与电动摩托车如何界定
- 三星s20如何关机
- oppo手机如何改变应用图标
- 华为荣耀play3如何隐藏应用
- 如何教老婆
- 如何获取健康通行码
- 美的洗衣机如何清洗内胆