1,265
社区成员
发帖
与我相关
我的任务
分享如何做好code review？
软件工程中一直在强调code review的重要性，但在我们部门中，code review做得并不是很好。负责人意识到了这一点，想有意识的来做一下。问题随之而来，code review都应该做些什么？
说起来，code review应该是从编码规范出发，发掘代码中存在的不符合编码规范的东西。但实际上，我们的编码规范中更多的是对编码格式和命名方法的要求，如果简单的来看编码格式，我觉得根本就是没有必要的，有个好的IDE，全部格式化一下，很容易就统一了。命名方法，虽然重要，但大家都编了一段时间的程序，一般不会只以a、b、c来命名吧！
这就是我的困惑所在，code review应该怎么做？code review的目的是为了提高软件产品的质量，如果仅仅做我上面提到的一些工作，似乎根本就与质量搭不上什么边。
请各位就自己所想，结合自己遇到的实际情况，谈谈如何做好code review。
说起来，code review应该是从编码规范出发，发掘代码中存在的不符合编码规范的东西。但实际上，我们的编码规范中更多的是对编码格式和命名方法的要求，如果简单的来看编码格式，我觉得根本就是没有必要的，有个好的IDE，全部格式化一下，很容易就统一了。命名方法，虽然重要，但大家都编了一段时间的程序，一般不会只以a、b、c来命名吧！
这就是我的困惑所在，code review应该怎么做？code review的目的是为了提高软件产品的质量，如果仅仅做我上面提到的一些工作，似乎根本就与质量搭不上什么边。
请各位就自己所想，结合自己遇到的实际情况，谈谈如何做好code review。
...全文
请发表友善的回复…
发表回复
sole_eagle 2003-08-17
- 打赏
- 举报
mark
shizi_mhy 2003-08-16
- 打赏
- 举报
mark
robert44153 2003-08-15
- 打赏
- 举报
看了上面的文章，受益匪浅。
我觉得作CODE REVIEW主要看代码的结构是否清晰，接口是否简洁明了，是否有冗余，重复的代码，还有，那就是要有清楚的注释。
我觉得作CODE REVIEW主要看代码的结构是否清晰，接口是否简洁明了，是否有冗余，重复的代码，还有，那就是要有清楚的注释。
wuhanfengchao 2003-08-15
- 打赏
- 举报
关注中···
xdeadxdead 2003-08-10
- 打赏
- 举报
让新手Review Code,老手提问题，可使新手在最短的时间内，了解公司的开发模式，融入团队的开发
gmc007 2003-08-04
- 打赏
- 举报
mark
zhuyanwei 2003-08-04
- 打赏
- 举报
Code Review 就是walkthrough, 换一个说法叫做trace all.
所有设计从脑子里走一遍（最为重要）
所有代码从机器上走一遍（比较重要）
如果是烂代码，重新写一遍
至于代码的规范顺手纠正。
需要的人：聪明，有耐心，经验丰富
所有设计从脑子里走一遍（最为重要）
所有代码从机器上走一遍（比较重要）
如果是烂代码，重新写一遍
至于代码的规范顺手纠正。
需要的人：聪明，有耐心，经验丰富
longsansan 2003-07-10
- 打赏
- 举报
code review需要下列方面条件：
1、好的设计及文档
2、正确详尽的编码规范
3、强烈的责任心
4、财大气粗的公司
1、好的设计及文档
2、正确详尽的编码规范
3、强烈的责任心
4、财大气粗的公司
xiaohaiz 2003-07-09
- 打赏
- 举报
总是在说为什么要code review，怎么做code review.
不要忘记一点，傻子都能写出计算机能懂的语言，但是只有好的程序员才能写出人能看懂的语言。
作code review的基础，估计没有多少看着能“懂”的语言。因为优秀的程序员实在是太匮乏了。而平庸的经理（项目经理，产品经理，etc）却是比比皆是。
另外一点，做code review一定要精力充沛，而且一天不要时间太长，中间得注意休息。
不要忘记一点，傻子都能写出计算机能懂的语言，但是只有好的程序员才能写出人能看懂的语言。
作code review的基础，估计没有多少看着能“懂”的语言。因为优秀的程序员实在是太匮乏了。而平庸的经理（项目经理，产品经理，etc）却是比比皆是。
另外一点，做code review一定要精力充沛，而且一天不要时间太长，中间得注意休息。
skywalker117 2003-07-01
- 打赏
- 举报
（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，的确使得项目的测试周期变短，并且最后缺陷密度以较快的速度收敛。
以上是我个人的一些观点，欢迎大家一起讨论。
说到为什么进行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，的确使得项目的测试周期变短，并且最后缺陷密度以较快的速度收敛。
以上是我个人的一些观点，欢迎大家一起讨论。
chrislois 2003-06-07
- 打赏
- 举报
up
yfd 2003-06-07
- 打赏
- 举报
mark
swimcong 2003-06-01
- 打赏
- 举报
收藏
uniware 2003-05-30
- 打赏
- 举报
大家能不能把具体的实践贴出来？
我所在的公司以前为了应付CMM，也弄过CODE REVIEW，可是不仅没有查出什么实质性的问题，
还打击了部分程序员的积极性。哪位所在的公司做的比较规范和成功，请把经验贴出来分享，
如何？
wengjiang 2003-05-02
- 打赏
- 举报
发表一下我的意见：
1. Code Review的目的我感觉有两方面：其一是规范化代码，使其有统一的风格，合符规范要求；第二是检查代码的逻辑，流程错误或一些其它低级错误；
2. Code Review的实施有助于降低整个项目的开发成本，规范化有助于降低维护成本并可以一定程度的复用，在测试之前发现问题比测试中或测试后发现问题及解决问题的成本要低得多；
3. Code Review个人认为应是同项目组的人员相互进行，只要对项目比较了解才能更多的发现问题，而且有时发现项目中其它成员的问题可能是自已的问题，对于成员的沟通及对整体的把握有好处；
4. 程序员最好的学习是看别人的源代码；
5. Code Review最好先用编译器等工具排除最基本的语法错误后再进行.
1. Code Review的目的我感觉有两方面：其一是规范化代码，使其有统一的风格，合符规范要求；第二是检查代码的逻辑，流程错误或一些其它低级错误；
2. Code Review的实施有助于降低整个项目的开发成本，规范化有助于降低维护成本并可以一定程度的复用，在测试之前发现问题比测试中或测试后发现问题及解决问题的成本要低得多；
3. Code Review个人认为应是同项目组的人员相互进行，只要对项目比较了解才能更多的发现问题，而且有时发现项目中其它成员的问题可能是自已的问题，对于成员的沟通及对整体的把握有好处；
4. 程序员最好的学习是看别人的源代码；
5. Code Review最好先用编译器等工具排除最基本的语法错误后再进行.
wangfc 2003-04-30
- 打赏
- 举报
简单说，比如，变量的相关性，函数的相关性，对像的.......很多乱七八ZAO的原则。
wangfc 2003-04-30
- 打赏
- 举报
看着大家写了这么多，都没看完，就说两句了。如果重复了，不要说啊。
我觉得code review的目标是提高代码本身的品质，是说在保证功能的情况下，让实现功能的
代码变得易于维护和阅读。维护是第一目标。
推荐的书目我觉得是＜代码大全＞。至于用code review来提高系统质量是不太可能的。
对于同样功能的代码，能够写出质量完全不同的代码。在XP编程或者生命周期里，重构和
维护是最多的，所以，代码的可重构性和易重构性是很重要的。同时，系统分析在这个
过程也有很大的影响。
我觉得code review的目标是提高代码本身的品质，是说在保证功能的情况下，让实现功能的
代码变得易于维护和阅读。维护是第一目标。
推荐的书目我觉得是＜代码大全＞。至于用code review来提高系统质量是不太可能的。
对于同样功能的代码，能够写出质量完全不同的代码。在XP编程或者生命周期里，重构和
维护是最多的，所以，代码的可重构性和易重构性是很重要的。同时，系统分析在这个
过程也有很大的影响。
metalbreeze 2003-04-29
- 打赏
- 举报
我听说国外的公司review的话是
挑一段(一部分)有代表性代码,不是全部的,
一个团队的对此段代码讨论,
这样发现问题,而不是找出全部问题,对各自的review,和编码都有好处,更重要的是review时间节约了效率高了--------找到一个平衡点
挑一段(一部分)有代表性代码,不是全部的,
一个团队的对此段代码讨论,
这样发现问题,而不是找出全部问题,对各自的review,和编码都有好处,更重要的是review时间节约了效率高了--------找到一个平衡点
meiwen 2003-04-29
- 打赏
- 举报
本人认为，交换CodeReview效果较好，但在有限的时间内最大限度地发现问题，还需要具备以下条件：
第一，设计流程要清晰说明，代码结构要清晰。
第二，接口人明确。
第三，规定每人必须发现的问题量。
其实，代码走查也是个学习的机会。
第一，设计流程要清晰说明，代码结构要清晰。
第二，接口人明确。
第三，规定每人必须发现的问题量。
其实，代码走查也是个学习的机会。
Junmy 2003-04-29
- 打赏
- 举报
我的意见有以下几点：
1、CodeReview应该分为几个步骤来进行，首先是初级的审查，审查的内容应是对代码命名、风
格、逻辑等，查看是否合乎编码规范，是否有明显的逻辑问题及错误。
2、第二步应该是按照前期的设计文档(类图、顺序图、状态图等)进行审查，查看是否达到了设计要
求。
3、CodeReview不可能查看全部的代码，只能对其比较关键核心的代码进行审查。
1、CodeReview应该分为几个步骤来进行，首先是初级的审查，审查的内容应是对代码命名、风
格、逻辑等，查看是否合乎编码规范，是否有明显的逻辑问题及错误。
2、第二步应该是按照前期的设计文档(类图、顺序图、状态图等)进行审查，查看是否达到了设计要
求。
3、CodeReview不可能查看全部的代码，只能对其比较关键核心的代码进行审查。
加载更多回复（93）
