code review方面的观点

观点1：

Code review：实质是人工源码查看

观点2：    

code   review的目的：  
  1：检查开发人员编码是否规范。     

  2：检查特定开发人员所做模块是否是否影响其他的模块。  
  3：特别是软件升级时，检查修改或添加的代码是否会影响其他部分。

观点3：

以下是我的一些个人看法。  
   
  1.为什么要进行code   review?  
  为完成一个软件项目，需要多个成员的参与，因此存在编码风格和质量上的差异，尽管在一个项目开始之初，团队内部就对编码进行了格式化上的规范，但是在实际过程中，还是搀杂了许多个人的因素，比如习惯，思维方式等等。当然，从开发角度上说，这些差异的存在是合理的，而且每个程序员自身都有鲜明的个人特色。但在整体的角度上讲，差异存在越多对项目代码的可读性及维护性影响也越大，又由于一些人可能限于水平，在编码过程当中引入了较低级且显而易见的错误，比如，资源没有释放，造成泄漏，这些隐患如果不是通过code   review来发现和纠正，那么通过测试是很哪达到目标的，也不利于项目的进展，因为项目是一个有一定周期的活动，随着时间的推移，积累的问题会逐渐增多，到一定程度的话就很难再去着手处理，“防患于未然”，确保质量，同时也是提高整个开发团队的开发水平，我认为这是code   review的必要性所在。  
   
  2.code   review的方式：  
  code   review在开发中属于“额外”工作量，属于附属的监管机制，由于它是“额外”的，因此所发生的频率，及什么人负责和参与，都需要根据这个特点进行安排。我认为负责code   review的人应该是项目小组组长及系统架构/设计师。code   review的时间安排可以根据项目大小和周期长短来定，小项目（如3个月内）可以定在10天内一次，大的项目（6个月以上）可以在半个月内一次，次数的安排也要讲究，在项目的开始之处应该安排密一些，而在项目进展到一定的程度后，周期可以更长，一个月内一次。这种安排出于以下考虑，一是项目成员对项目的认知在开始阶段比较粗浅，问题较多，因此需要及时的纠正；而当项目成员随着进展而成长后，有很多问题可以为成员自己所避免，因此安排code   review的次数应该减少。除了纠正错误和问题之外，code   review可以通过相关人员的参与，来交流一些技巧和宝贵的经验，以讲解和讨论的形式获得提高，因此成员的参与积极性应该比较高。  
   
  3.code   review的一些问题：  
  中国的程序员每个人都很有特色，因此，在code   review中应该贯彻一种包容平和的思想，使每个人都能够以平和的心态潜移的接受，这样效果才能够达到。

观点4：

我们是这样做code   review的：  
   
  0、确保分析和设计的优秀，并按照设计结果进行编程，对代码评审才有意义；  
  1、意识到评审是需要专人付出时间去做的具体工作，这会导致多投入一些成本，必须达到共识；  
  2、针对项目，进行编程规范的客户化，而不是照搬书上的或者网上的，不求“四平八稳”，但求“事无巨细”；  
  3、编程开始前，对程序员做编程规范的培训；  
  4、根据编程规范、程序员的平均水平、评审预计投入的时间、评审如果不彻底可以承担的风险等因素，制作详细的评审表格，要非常具体，要检查什么，就在表格中表现什么，检查结果有“合格”、“返工”、“有待改进”三个结果；  
  5、重点评审“菜鸟”提交的代码的低级错误，以示警戒；重点评审“高手”提交的代码是否存在逻辑错误，防止给系统留下隐患；  
  6、实话讲，我们做不到100％覆盖的代码评审，实际上，覆盖到60％——70％就不错了，评审成本是比较高的，而且中国的公司一般不肯在这方面多花成本，正因为如此，评审表格要合理，好操作，评审结果要立即通报出来；  
  7、继续开发工作，等待下一次评审。下一次评审的覆盖范围更小，但针对性更强了，我们一般做两次或者三次评审，严格的UAT测试会发现评审时未发现的问题，这是另外的话题了。  

观点5：

关于code   review的文章很多，关键还是你想化多少成本以及达到多高的标准。如果code   review查一个错化的时间比unit   test查同样的错的时间多就得不偿失了。SEI的PSP，TSP有些数据可供参考。我个人认为code   review查出来的错不能少于unit   test查出来到错的10%(否则会化过多的成本在unit   test上)，也不能多于50%(否则化过多的成本在code   review上)。   

我觉得首先得定好code   review的目的。一般是以差错为目的，辅助与优化(可读性以及效率等)代码。   
   
  自己做code   review的效率往往很差(我指的是使用IDE来排除语法错以后的code   review。没有IDE的话，自我code   review对查语法错还是很有效的)，原因是自己很难跳出写程序时的思路。所以，code   review一般至少有两人,也可以是一个team。Team的code   review往往做些分工，比如查初始化，算法，内存问题等。每个人做两样以上并保证同一类错有两个以上人来查。  
   
  Code   review的另一个重要环节是总结会议，大家一起在会议上指出发现的错(会议不要太长)。没有这会议的话基本上code   review会变成走过场，而且这良好的互相学习的机会丢掉很可惜。一个需要注意的重要问题是不要造成作者和reviewer之间的矛盾，其方法很多。

观点6：

code   review应该是检查逻辑性的错误。当你review别人代码的时候，首先要搞清楚这段代码的目的，其次要询问这段代码是以什么一种方法实现这一目的的，大致判断一下代码是否是实现这一目的的最好方法（如果做了详细设计，那就应该是公认的最好方法了）。最后才是真正阅读代码，检查是否有逻辑上的错误，同时看看是否有违背命名规则的地方，是否有比较费解需要注释的地方。

观点7：

下面我谈谈我的看法  
  首先：做code   review是非常必要的，它不是QA的事；  
  其次：做code   review的目的：  
              1、正如楼上各位所说，按照一定的编码规范使代码规范化，便于后期工作开展；  
              2、通过code   review可以发现内存泄露、死循环、参数传递、返回码是否正确等等问题；  
  再次：为什么要做code   review   ？？？  
              如果前期的检视做的不好，在后期的集成、系统测试时花的时间就会成倍相应增多，得不  
              偿失，百分之八十的时间花在解决百分之二十的问题上，这样，产品周期就会无限期拉长。  
  个人一点愚见，各位大虾别见笑！！！！

观点8：

code   review   是一个很有效，能够尽早发现错误的阶段。在讨论code   review前，我们需要了解一下软件开发的目的，是满足需求。客户的需求是可用性，易用性；开发商更多关注的是程序的稳定性和可维护性等等；程序设计人员关心的我的程序每个类，函数写的是否合理。其实这都是需求的一部分。这些都是定性的说法。但是怎么定量的来度量诸如稳定性，可用性等等。我们现在有一些质量模型，但是每个模型都不是十全十美的。这些模型的一些量度应该作为需求的一部分尽早定义，这样以后的各个阶段工作才有意义。code   review可以说是代码走查，代码审查，意思是说读代码，提意见。现在有一些工具的出现把这个过程赋予了更多的内涵。这个阶段不动态的编译运行程序，是基于代码，对代码的本身进行分析和度量。关于度量，首先程序应该可度量，如果你的程序有7000行，只有一个函数，或者有7000个函数，每个函数只有一行，这样的程序是不可度量的，请您先去学习数据结构。

观点9：

我说一下我的体会,  
  code   review的职责和期望:有时会在code   review的时候发现设计的问题，但是code   review不应该对找出设计中的问题负责，这是软件架构的职责。code   review就是寻找出编码时不符合设计，不符合编码规范以及其他的一些违反编码原则的地方。code   review也不可能代替测试，它是在提交系统测试以前所做的一项工作。  
  如何做code   review：软件工程管理最重要的是对人的管理，如果小组成员不愿意做这项工作，那么有再好的流程也只是走形式。统一认识以后，就需要建立一些规范，也就是如何code   review时如何评价code的好坏，这需要有被大家统一接受的编码规范和软件规范。这里的软件规范是指详细设计时定义好的编码人员将自己的模块加入到框架中所需要遵循的一些规定。在进行code   review以前还有一件重要的事情就是代码的自文档化，也就是补充代码中的注释。无论你是边写程序边写注释还是在一个功能完成后写注释，注释总是不完全的。应该在这个时候补充完整，管理人员应该鼓励程序员做这样的事情，把写注释看成和其他人交流的工具。然后再开始进行code   review，我认为code   review不应该花太多的时间，抽查一下就可以，策略上有所倾斜，对功力较低的程序员花更多的时间。对系统核心部分的代码做更严格的检查

观点10：

发表一下我的意见：  
  1.   Code   Review的目的我感觉有两方面：其一是规范化代码，使其有统一的风格，合符规范要求；第二是检查代码的逻辑，流程错误或一些其它低级错误；  
  2.   Code   Review的实施有助于降低整个项目的开发成本，规范化有助于降低维护成本并可以一定程度的复用，在测试之前发现问题比测试中或测试后发现问题及解决问题的成本要低得多；  
  3.   Code   Review个人认为应是同项目组的人员相互进行，只要对项目比较了解才能更多的发现问题，而且有时发现项目中其它成员的问题可能是自已的问题，对于成员的沟通及对整体的把握有好处；  
  4.   程序员最好的学习是看别人的源代码；  
  5.   Code   Review最好先用编译器等工具排除最基本的语法错误后再进行.  

观点11：

（1）为什么进行CodeReview  
  说到为什么进行codeReview，就不得不说一说软件开发的几个阶段：需求分析（产品包需求、设计需求、设计规格）、SRS、概要设计、详细设计、Coding、UT、IT、ST。而在这整个流程中，每个阶段都有相应的Review工作，可以说Review是贯穿于整个软件开发过程的。比如在需求分析阶段，我们会对需求文档进行评审（此处用Review不大合适），在SRS阶段我们会对软件需求规格进行评审、在Coding阶段我们会对代码进行CodeReview或代码走读。此后，在UT、IT甚至是ST阶段，我们都可以定期或不定期的对代码进行走读或Review，直到项目关闭。可能有的人担心进行CodeReview是不是会很浪费时间，因为每次进行Review的时候，总需要一堆人聚集在一起，然后花2～3个小时看代码。事实上，根据实践经验，进行CodeReview是发现缺陷最有效的手段，而且也是效率最高的！通常情况下，CodeReview发现缺陷的效率是UT的7～8倍（缺陷数/每人时）。所以在Coding阶段一定要重视CodeReview。很多情况下，由于开发时间很紧张我们可能无法在项目组内经常性的进行CodeReview，这种情况下，我们可以采取代码走读的方式，通常是2～3个人，花1～2个小时对1K～2K的代码进行走读，效果是比较好的。  
  前面的帖子里面，有人说CodeReview只是在编码阶段进行，其实不然。CodeReview应该是贯穿于整个项目周期的（从Coding开始到ST完成）。并且，在进行CodeReview的时候，并不会说仅仅只能发现编码方面的问题，事实上，CodeReview同样可以发现需求阶段、设计阶段的问题，只是发现密度大小的问题。如果说在编码阶段进行CodeReview的时候，发现需求或设计方面的问题比较多，那么项目经理可能就应该停止当前项目的工作，回过头来对需求及设计文档进行审查。  
   
  （2）如何进行CodeReview  
  我觉得CodeReview应该根据项目紧张的不同时期，有不同的侧重点。  
  比如在编码开始阶段，CodeReview可能更关注于编码规范、接口、算法效率及合理性等方面的问题，在这一阶段可能会发现需求或设计方面的问题。  
  在编码的中后期，我们可能会更关注代码效率，是否有内存泄漏等较为深层次的问题。  
  在IT、ST阶段，由于这个阶段我们实际上已经开始做集成测试或系统测试，响应的也会有一些问题单。如果我们发现某个子系统或某个模块的问题单特别多，那么我们可能就需要对相应的模块进行CodeReview，这样做实际上会比IT或ST的效率高，因为构造测试环境、执行测试用例的开销是远远高于CodeReview的，而且很多问题我们很难用测试用例测出来，比如线程吊死、内存泄漏之类的问题。  
   
   
  （3）实际效果  
  Review无疑贯穿了整个软件开发过程，事实上，在需求或设计阶段引入的一个缺陷，越往后推，发现该缺陷的代价将是更大的（比如一个需求阶段的问题到了ST阶段才发现）。  
  而进行CodeReview，无疑可以极大的减轻UT、IT、ST阶段的测试压力，减少测试周期。  
  从我所经历过的项目过程来看，通过持续不断的CodeReview，的确使得项目的测试周期变短，并且最后缺陷密度以较快的速度收敛。  
   
  以上是我个人的一些观点，欢迎大家一起讨论。

观点12：

Code   Review   就是walkthrough,   换一个说法叫做trace   all.  
   
  所有设计从脑子里走一遍（最为重要）  
  所有代码从机器上走一遍（比较重要）  
   
  如果是烂代码，重新写一遍     
  至于代码的规范顺手纠正。     
  需要的人：聪明，有耐心，经验丰富