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

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

代码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开源，有需要的同学可以前往这个链接。