关于前端代码Review的一些思考

最近换了份工作,来到一个全新的前端团队。新团队有些同学可能之前全身心投入到业务开发中,对代码Review的必要性和基本流程了解不多,有滴同学可能还没听过CodeReview这个名词。

代码Review其实就是把代码贴出来让大家批斗的一个过程,对提高团队整体代码水平(如代码规范性、可维护性、设计合理性等)都有很大帮助。前端代码直接面向最终用户,代码Review更是应该作为一个专业前端团队必不可少的一环。

怎么组织一场代码Review呢?我觉得可以从下面几方面来考虑:

  • 前置条件:一系列合理的规范文档。没有规范就没有Review标准,没有统一标准Review就变得随意、收益不明显、不可持续;
  • 被Review的人:可以根据项目实际情况轮流担任。一般新同学被Review出来的问题会多点,但并不代表老同学的代码不需要被Review。代码Review本来就是一个互相纠正、互相学习的过程,每个人都有自己的亮点和不足;
  • 被Review的代码:最好不要直接从Git/svn同步,而是让被Review者自己挑选合适的代码放上去。这个合适有两方面需要考虑:一是代码规模必须适量;二是要挑典型代码,去掉关联不大或功能类似的代码段;
  • Review的形式和周期:考虑到实际情况,每次代码Review都指定至少一个主Review人,提前看代码并收集change set。然后召集组内成员在会议室看投影,一个个点来讨论change set,记录讨论过程与结论。这样做成本比较高,所以Review频率不要高于一周一次;
  • Review平台:Review重要的是协作和交流、分享与学习,工具是其次。挑选一个合适的Review平台,不是要用工具取代人的职责,只是让Review代码能更方便,能归档查询所有Review历史。

特别说下Review平台。之前我们WED团队使用的是Trac下名为PeerReview的插件,由于Trac比较重量级,而且这边已经有现成的各种类似平台,再搭一套Trac有点重复建设。开源的Review系统试过几个,如groogle,感觉和理想中还差那么一些。于是自己花了几天时间,写了个简单的Review系统,下面是两张截图:

(代码可以压缩为zip包上传到Review平台,自动解压后通过目录树选择一个文件来Review)

(使用SyntaxHighlighter高亮代码,点击行号,可以查看/新增Review意见,有Review的行号会高亮)

总之,说得再好没用,还是要让代码Review机制迅速用起来,在摸索中前进,在前进中摸索。

update @ 2012.12.03,本文提到的我写的这个Coreview系统,已经在Github开源,有需要的同学可以前往这个链接

本文链接:参与评论 »

--EOF--

提醒:本文最后更新于 1930 天前,文中所描述的信息可能已发生改变,请谨慎使用。

Comments