|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-08-28
既然名字是code review，就不要太涉及业务相关的东西，把关注点集中在coding相关的方面来，除了1，2条外，我觉得最重要的是代码的风格和一些好的习惯，比方说如何提取一个方法，如何对代码进行refactor和抽象，要通过revie潜移默化的提高整个team的代码水平，我觉得这个才是code review的最终目的。
至于需求相关的东西，其实不应该在code review中解决，应该是测试关注的问题。 |
| 返回顶楼 | |
|
发表时间：2008-08-29
fengzhang 写道 我看了大家的讨论，我个人认为大家对于code review的有一些理解是有偏见的。根据我的经验，code review的要求如下：
一、review执行者要求 1.精通项目组所使用的技术 2.了解整个系统或者一个模块的业务过程 3.具有很强的责任感和耐心 二、code review的基本要求 1.找出不符合项目规范的代码 2.找出可能在不同的情况下会出现异常的代码 3.是否是完全符合业务要求 4.是否对其他的机能造成影响 以上4点中，后两点是最重要的，但是好多公司和个人往往把1，2点作为重点，也就导致大家认为更本没有必要的想法了。对于业务的检查是没有任何工具能够代替的。 这个靠人来看？我很佩服你们做这个事情的人 
|
| 返回顶楼 | |
|
发表时间：2008-09-01
CMMI 3级就会制定标准的Code Review范本，照着上面的做就是了，感觉还很有用的
|
| 返回顶楼 | |
|
发表时间：2008-09-02
kimmking 写道 传统的公司中，pair不可想象，
试问：领导者如何会乐意见到每时每刻都有一个人在“闲”着！ 理想的pair还是很不错的选择,问题是pair之间的互动并不像某些人想象中的那样,这种情况下,你怎么办? |
| 返回顶楼 | |
|
发表时间：2008-09-02
younggun 写道 xuby 写道 什么pair/review这些方法都不好,好的办法要从中国传统智慧中去寻找.
南北朝时北朝有个皇帝赫连勃勃,要建首都(统万城)的城墙.为了最大程度保证质量,他把团队分为两组,一组施工,一组质监.施工组建完一段墙后,质监组过来做检查,检查办法是用铁枪使劲往城墙上戳,那么结果无非两个,一是把墙戳个坑,或者是墙毫发无损. 对于第一种情况,皇帝的措施是这样的:把施工组的人全部砍头.第二种情况的处理大家可能猜到了,就是把质监组的人杀掉. 采取这种措施的成效非常喜人:近2000年过去了,这个统万城依然屹立不倒. 诸位认为这个质保措施用于软件业,会有什么效果? 你这个方法太极端了，我知道一个比较好的例子是降落伞工厂会让生产工人从自己生产的降落伞中抽出样品来试用。 两位都很极端,也很幽默. 哈哈!!! |
| 返回顶楼 | |
|
发表时间：2008-09-05
andyhu1007 写道 code review: 费时，费力，交流麻烦。推荐pair。
code review 还是有必要的。不是所有人都喜欢Pair的。这要看组织文化了。 |
| 返回顶楼 | |
|
发表时间：2008-09-05
关键是Review的 Scope 很重要。大家不妨在这个话题上面探讨下经验。有那些东西值得Review，有哪些东西是不值得去花这个时间去Review的。
公司性质不同也许Review的侧重点也不同。比如外包公司可能文档之类的Review就要求的比非外包公司严格。 |
| 返回顶楼 | |
