java中的代码分析和任务分配
我最近看了一个关于喷气推进实验室的一部分如何进行代码审查的有趣的演讲 。
基本上他们有一个工具（磨砂）：
- 在代码上运行各种代码分析器
- 与有问题的开发人员进行匹配
- 为该开发者创build一个任务/错误。
那么开发者可以：
a）同意（解决问题 – 它消失）b）不同意c）讨论
该工具保持所有对话的踪迹。 然后在他们的每周会议上，他们只讨论不同意/讨论项目。
我想知道是否有人在Java中遇到类似的工具？
例如，我可以使用声纳 – 进行代码分析，但是没有办法自动创build任务或跟踪数字对话。
任何build议，欢迎！ 谢谢。
Atlassian有Crucible ，但是它是付费软件。
Sonar 2.7增加了与SCM的附加集成，以便您现在可以查看哪个开发人员最后触及了特定的代码行。 http://www.sonarsource.org/sonar-2-7-in-screenshots/
虽然这是一个手动过程，但使用Sonar Eclipse插件，可以通过右键单击违规视图，直接从违规视图快速创build任务，并且一些错误的字段将被预先填充。 希望Sonar插件的未来更新将添加SCM中的最后一个提交者信息，以填充错误/任务中分配的字段。
更新：
声纳2.8和2.9增加了手动触发Sonar评论的function。 http://www.sonarsource.org/sonar-2-8-in-screenshots/ http://www.sonarsource.org/sonar-2-9-in-screenshots/
缺less两件事是自动检查违规情况并将其集成到Bugzilla等外部任务跟踪系统中的一种方法。
更新2：
声纳3.1增加了一个扩展点，将外部跟踪与声纳违规和审查过程（ function细节 ）联系起来。
使用这个扩展点，最新的JIRA插件（1.0）允许您为Sonar引发的违规创build/链接JIRA问题。 JIRA问题和插件详细信息页面中的更多细节。
我还没有看到与其他问题追踪系统整合的计划。
我们有一个相当成功的过程，可以做你想做的事情。
我们有一个很大的pipe理应用程序，由20多个模块组成。
- 一切都在颠覆（任何scm会做）
- 每一次代码更改都应该通过Jira（但是可以使用任何东西，从螳螂到bugzilla）
- 你必须在提交中放入一个jira问题id; 一个预先提交的钩子提交谁提交，所以所有的提交符合规则
- 通过Hudson持续集成（再次，您可以使用其他产品）
- DEV / TEST / QA / PROD分支
- 通过自定义脚本，哈德森可以接受一个或多个jira问题，创build补丁并将其应用于QA，编译和部署; PROD是经过validation的QA分支的复制时间（严格的validation规则）
- Jira中的自定义字段可使过程自动进行：例如，您可以通过在Jira中指定所需的补丁来触发补丁。
在某些脚本中检查最新的票据/提交，运行PMD / Checkstyle / Findbugs等等，并在需要的时候在Jira中打开新的问题（或者在现有票据上添加一些自定义字段值，您决定）将是相当容易的。 您可以为整个过程定义规则，因此您可以基于jira问题状态阻止补丁或发布。 你可以通过这种方式实现你想要的（甚至更多）。
其结果是开发人员承诺，他们甚至不需要知道分支的工作原理，只要他们对jira问题有一定的纪律，就可以自动发生并保持安全。
其他人提到Sonar，但似乎没有人提出这样一个事实，即从2.8 Sonar开始，现在支持手动代码评论 ： http : //docs.codehaus.org/display/SONAR/Manual+Reviews
结合SCM插件，这听起来非常接近你正在寻找的东西。
在我的新公司，我们已经开始使用GitHub进行SCM项目。 GitHub提供了精彩的综合代码审查工具（基于提交）。 只要去任何提交，并在一行，文件或整个提交添加您的评论。
老实说，我很惊讶，没有人提到审查委员会 。 虽然它不是一个代码分析工具（但是你可以自动运行PMD / CheckStyle / FindBugs），它可以让你做一些你所要求的事情。
我们正在使用我们的主要应用程序之一。 基本上这个过程是这样的：想要签入他/她的更改的开发者创build差异文件，将其上传到审查委员会并分配审查组（或单个人）。 它可以让你指出问题，对它们进行评论和纠正你的代码（做增量代码审查）。
基本上，如果我要构build签入过程，我会强制所有用户运行自动化testing（不仅仅是unit testing，还包括UI和集成testing），FindBug和CheckStyle以及所选的一组规则，然后如果它是干净的，代码将由审查委员会审查（在这一点上肯定是语法正确，不会引入问题，但没有必要是有意义的）。
听起来像一个非常有趣的谈话，我一定会看。 但乍一看，我很怀疑：
- 代码分析器的错误警告的数量通常相当高，即使是先进的自动化严重等级（如EFindBugs）。
- bug /问题跟踪器中的开放错误数量不应该太高，特别是在干净而敏捷的开发中。
因此，在我看来，只有less量的绝对正确的代码分析器警告（例如封装周期）适用于描述的擦洗过程:(
因此，我认为一个更好的解决scheme是不完全自动化这个错误报告，但强烈支持代码审查，手动也考虑分析仪的警告。 使用一个工具，你可以轻松地将小代码评论包装成问题，真的有助于这一点。 FogBugz做得非常好（例如，见这个video： http ： //www.youtube.com/watch？v = r5HNI9aMzOE＆feature = player_embedded）。
总的来说，这个过程与Scrub过程非常接近，但是通过一个人工审查步骤来避免由于错误的警告而产生大量的错误。
您可以查看Sonar的SCM Activity Plugin 。 它不会做你所要求的，但是可以将任务添加到你正在使用的任何任务引擎中。 至less它会为你查询SCM。
我们使用ReviewClipse ，它连接提交和评论。 所以你唯一需要做的就是读取提交消息，并检查更改（在Eclipse比较视图中由reviewClipse显示）是否与消息匹配。
ReviewClip缺less什么，是一个过程/支持，在评论中发现的缺点不仅会被写下来，而且被固定下来。
我曾经推荐过一个免费的代码分析工具stan4j（ http://stan4j.com/ ）。 但是它的社区免费版只支持500个类。它不能完成任务分配，只能进行代码分析。
代码度量的魅力是什么？
也在这篇文章中。 还有其他人推荐的代码指标。
