|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-07-08
rabbitbug 写道 让质检组的人来code review,与他们的测试有何区别?
还叫什么code review? xuby 写道 毫无疑问是 test.
质检组的人不会管你砖砌的是不是很"面向对象",也不会管你用了一个"资源"(比如一个铁锹)之后有没有"释放". 而且他基本上是黑盒测试,只管拿条大枪往墙上戳. test说白了只是一种工具，一种保证软件质量的工具，code review是个专业性和主观性都比较强的活动，用工具也只能发现那些条条框框的东西，如check style |
| 返回顶楼 | |
|
最后更新时间：2008-07-10
我们是采取小组形式的code review,这样占用的资源相对比较少。
|
| 返回顶楼 | |
|
最后更新时间：2008-07-10
review好啊，不review自己有时候头一发热，就不知道自己在干什么了。书读百遍，其义自现，我读不了百遍，百人读一遍就好了。
|
| 返回顶楼 | |
|
最后更新时间：2008-07-11
JavaJason 写道 下面是我和公司一同事讨论得出的一个方案，供大家参考（我们考虑的重点是可行性、实际效果和执行效率） 1． 开发刚开始的阶段，由TL和PM召集大家坐在一起进行几次review（至少3-5次） 其实这一条还有一个含义，减少返工 |
| 返回顶楼 | |
|
最后更新时间：2008-07-16
呵呵，Review的人能不能认真做Review是个问题。
|
| 返回顶楼 | |
|
最后更新时间：2008-07-16
最好有个check list， 用来保证coding style， class design等的一致性。(开发中自我约束)
然后peer review,由熟悉业务或者senior的人来完成。（开发完成测试前） 还有team review,把比较重要的更新集体检查（学习）（一个礼拜左右） 然后review应该有记录， 有改进。每次有不同的关注， 而且层次日渐提高 可以在building做一些自动化， 比如说用code source anaysis 工具 |
| 返回顶楼 | |
|
最后更新时间：2008-07-21
我看了大家的讨论，我个人认为大家对于code review的有一些理解是有偏见的。根据我的经验，code review的要求如下：
一、review执行者要求 1.精通项目组所使用的技术 2.了解整个系统或者一个模块的业务过程 3.具有很强的责任感和耐心 二、code review的基本要求 1.找出不符合项目规范的代码 2.找出可能在不同的情况下会出现异常的代码 3.是否是完全符合业务要求 4.是否对其他的机能造成影响 以上4点中，后两点是最重要的，但是好多公司和个人往往把1，2点作为重点，也就导致大家认为更本没有必要的想法了。对于业务的检查是没有任何工具能够代替的。 |
| 返回顶楼 | |
|
最后更新时间：2008-07-23
项目早期或新人加入时最初的代码要review，之后抽查就可以
|
| 返回顶楼 | |
|
最后更新时间：2008-07-23
code review
1.code格式和编码规范用工具检查即可，省时省力我用jtest 2.每本代码必须有资深程序员来review，这个review就涉及重构了，它往往能发现一些代码结构的弊病。 |
| 返回顶楼 | |
|
最后更新时间：2008-07-23
fengzhang 写道 我看了大家的讨论，我个人认为大家对于code review的有一些理解是有偏见的。根据我的经验，code review的要求如下：
一、review执行者要求 1.精通项目组所使用的技术 2.了解整个系统或者一个模块的业务过程 3.具有很强的责任感和耐心 二、code review的基本要求 1.找出不符合项目规范的代码 2.找出可能在不同的情况下会出现异常的代码 3.是否是完全符合业务要求 4.是否对其他的机能造成影响 以上4点中，后两点是最重要的，但是好多公司和个人往往把1，2点作为重点，也就导致大家认为更本没有必要的想法了。对于业务的检查是没有任何工具能够代替的。 3.是否是完全符合业务要求 4.是否对其他的机能造成影响 请问做这两点需要多少时间和精力，什么样的人能很了解业务呢？项目经理还是业务经理？ 不仅要了解业务还得精通技术，这样的人好像不好找啊 呵呵 请赐教 |
| 返回顶楼 | |
