般若菩提(丁丁)  
日历
<2005年9月>
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678
统计
  • 随笔 - 31
  • 文章 - 2
  • 评论 - 103
  • 引用 - 16

导航

与我联系

搜索

 

常用链接

留言簿

我参与的团队

随笔分类(18)

随笔档案(31)

Golden OpenSource

好友

积分与排名

  • 积分 - 50705
  • 排名 - 1208

最新评论

阅读排行榜

评论排行榜

 
 

经历很多内部培训程序员的培训方法和课程,感觉相当来说CodeReview这个内部制度,对程序员,尤其是像我这样资历较笨拙之人有很好的技术提高促进作用。

 

但如果仅应付制度,完成过场,则大家只感其累无有利处。

故而根据本人经验拟定一CodeReview细则,希望对大家有所帮助,同时恳切求大家意见经验。

 

1、确保一周之内必须有一次至少四十分钟CodeReview

2、各小组人数不要超过10人,每组至少有一人有熟练编辑经验,同时具有局部模块设计能力,并且此人作为   小组组长,最好能保证一个CodeReview小组成员来自一个开发组。

3CodeReview总体粗分可以分为:

A、分析每人代码是否符合编程规范等

B、分析经典有缺陷代码

C、分析经典优秀代码

D、通过分析部分代码来映射反观设计要点

E、分析代码现场实施重构

4、每5CodeReview中必须保证 DE 至少两次

5、每次CodeReview需要提交一份记录,包含到会者会议时间

    A/B/C时罗列讨论到的编程规范等名称

    D时要对讨论的大纲记录

    E时罗列重构方法名称

6A/B要由组长组织,由小组成员轮流发言。C/E 组长参与讨论。D 组长主持,成员为辅。D/E还需要定期邀请其他有经验人员主持。

7A/B/E 依据的代码,均可以由组员各自都提供,组长挑选。

 

posted on 2005-09-20 19:31 般若菩提 阅读(1956) 评论(4)  编辑 收藏 网摘
评论:
  • #1楼  bluse[未注册用户] Posted @ 2005-09-20 20:39
    我认为首先要改变的是,观念。
    CodeReview的目的是通过交流的形式提高member的能力。

    当然改变这个观念,不能采用说服教育的,或者纸面上的东西-规范来告诉你的member
    要靠lader的积极的准备,根据member的实际情况来觉得做哪方面的补充,这个认识的过程本身其难度,不言自明。

    那个lader有这个能力,有这个时间愿意花费如此精力呢?

    更何况做软件的,很少有不被进度,bug等追赶着呢?

    所以我的看法是,只有靠自己了,自己让自己codereview,自己偷偷地review别人的code吧,依靠别人也要主动地依靠。

      回复  引用    

  • #2楼  Cavingdeep       Posted @ 2005-09-20 21:20
    Code review的作用做好了的话还是很大的,况且这个概念已经被很广泛的验证过了^_^
      回复  引用  查看    

  • #3楼  komantian[未注册用户] Posted @ 2005-09-21 21:30
    good.
    希望经常看到这样有可操作性的文章.
    我总是喜欢刀刀见血的搞法.
      回复  引用    

  • #4楼  玉开       Posted @ 2006-02-09 13:08
    好文   回复  引用  查看    




发表评论

昵称: [登录] [注册]

主页:

邮箱:(仅博主可见)

评论内容:

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 240663




相关文章:

相关链接:

 
Copyright © 般若菩提 Powered by: 博客园 模板提供:沪江博客