Sonar手动审查代码初体验

为了在部门内部推行code review这一活动，几个月之前开始寻找工具的支持，开始相中的是Jupiter这一eclipse插件，刚开始还写了一份user guide（见附件），但是后来我发现它比较笨拙，显著的缺点是每次review都要分reviewID，保存的数据格式是xml文件，总感觉不是很让人放心，另外跟公司内部的SCM结合的不是很好。当然它也有优点，比如跟eclipse结合的很好，查看源代码比较方便，而其它的个人评审和团队评审以及修复等等各种阶段性的活动也是一大亮点。

 

刚开始接触sonar时，让我眼前一亮，它的核心功能是整合PMD、checkstyle、Findbugs等等静态代码检查工具，生成各种数据报告，可以说是我目前为止见过最为强大的代码质量管理工具。由于自己负责的模块马上进入code review阶段，于是乎我就想藉此机会体验一下Sonar的手动代码审查功能。

 

首先，预览一下我的sonar的主界面：

关于Dashboard中的质量数据不是本文讨论的重点，如有机会我将会另开一文详细介绍。

点击上面的Violations，然后选中你要查看的java文件，会出现下面的界面（感觉有点隐蔽）：

 必须选中Violations，跟每一个Violations关联在一起，将鼠标移动到一条Violation上，会出现review的字样（有些因为浏览器的问题不会出现review字样，建议使用chrome浏览器）：

 也就是说如果没有Violation，就不会出现review的字样，如果review人员发现逻辑上的功能错误，就不知道在何处写上review意见了，这是Sonar的手动审查功能最大的弊病。

旁边的“Flag as false-positive”选项的意思是可以将当前Violation标记为误测，表示本来是没有问题的，标记之后，当前Violation不会再在页面上出现（但是Violations数目不会及时更新），你可以按照下面的操作再次找到它：

另外，你可以在别人添加review之后可以追加自己的review信息：

 

 感觉有点像论坛回复的味道呵，这样挺好的，能够在线下及时保存review人员的想法，让他们的想法尽可能的激烈碰撞。

还有一点不是很爽，就是在每次添加review的时候，Sonar都是默认将本次review分给了自己：

 这个默认做的不是很好，因为每次review大多数的时候都是assign给同一个人，建议大家注意这点，不要本来分给别人的Violations却分给了自己。

最后，在团队评审的时候，可以到主页的reviews去查找：

 Sonar默认显示open的reviews，而且只显示分配给了自己的reviews，如果要查看某个project的所有reviews，选择搜索条件即可：

总结

感觉Sonar的手动代码审查功能仅限于静态代码检查工具检测出来的Violations，而不是review人员自己添加一些reviews，但是我们应该看到的Sonar的优点，它的质量报告分析很强大，而且它也在不断发展中，我相信，Sonar在代码质量管理方面将是很多人一个不错的选择。