I've been wanting to better organize a structured code review on our project. So today I'm looking at the CSDL Jupiter Code Review Tool.
It looks promising, in that no external DB is required. It stores all review info in xml documents that are shared through our normal CVS project. It's an Eclipse plugin, which will make it easy to install and get our developers up to speed.
And they have a nice user's guide.
I'm hoping it fulfills our needs, and I'll post the results of my review after a day or so of use. It should be a big improvement over the print / distribute / highlight review!
Subscribe to:
Post Comments (Atom)
3 comments:
I haven't taken a very close look at this tool, but a good code review tool would be nice. Jupiter appears lacking in a few ways.
Currently, we use a Perl script that reads recent commit history from source control and displays each diff. Hitting enter takes you to the next commit/diff. It works well for us, but we still have to take notes manually (on paper).
Jupiter doesn't appear to do anything like this. Are you supposed to sift through entire code files? We do reviews every week, not a the end of a project. I just want to see the few lines that were added/edited during that time. I guess I could use Eclipse's "Compare with repository", but that's a lot more work than my Perl script.
I also don't like their process. Each reviewer works independantly and then as a team they go over the items found. You should have the programmer available at the time of code review. However, it might work well for a distributed team or when a large number of reviewers are involved.
Perhaps it wouldn't be much work to link Jupiter to the commit history. Perhaps just "prev/next modification" buttons. If it did, it would probably be a fantastic product.
Alternatively, a separate plugin could be developed for browsing the commit history. (What's built into Eclipse isn't so good at this.) That might even be better. Jupiter could stay as it is in that case.
---
Of course, one should always use automatic programs such as CheckStyle and FindBugs to handle obvious issues before a code review. It would also be nice if Jupiter used an alternate CheckStyle/findbugs configuration with very strict settings to help the reviewer identify problematic areas (like high complexity). But I guess one could do that manually.
I have to agree that code diffs are really needed in Jupiter. It's not natural to have to figure out which revision to diff with.
I tend to like the process, but we need to test it out more first.
I'd also like a tool that allows code reviews before committing to the repository. Jupiter only works for code that has already been commmitted.
I still need to write the followup post that will contain more of my analysis.
I have gone though this tool. it looks good but after creating one review id linking new files to it is not possible(plugin for Eclipse3.2) which is a draw back for it.
Post a Comment