"Peer Code Reviews Made Easy with Eclipse Plug-In," from DevX, shows usage of an Eclipse plugin called "Jupiter," which automates the code review process for teams, providing steps for individual and team reviews and helping save the review artifacts. Code reviews are basically peer reviews, although where in development they take place is often variable. For some sites, code reviews are suggested but often skipped; for others, it's a formal step before code is promoted to a publishable revision; for some, code reviews are meant to be done immediately as the code is written (this is one of the functions of the non-coding member of a pair programming team.) Lastly, some coding environments simply ignore the possibility of code reviews, relying on either programmer skill or (hopefully) tests to catch coding inefficiency. A plugin like this caters to the first two groups, while having some application to the last group as well. The ones who skip code reviews will appreciate automation to make them easier to track and - for that matter - implement, as code reviews with Jupiter don't require the reviewers to all attend a single meeting, where one person tends to dominate the review at a time. The formal reviewers will appreciate the tracking of artifacts, as one doesn't have to remember suggestions made during a meeting. Artifacts are automatically shown with the code being reviewed, making integration fairly easy. The teams that don't rely on code reviews at all can use the tool to implement the practice. The agile programmers among us tend to review as the code is written, which often has its own benefits (and limitations), and wouldn't quite need such a formal tool. What do you think of code reviews? What about the applicability of this particular tool?
- Posted by: Joseph Ottinger
- Posted on: June 14 2006 12:52 EDT
- Re: Peer Code Reviews Made Easy with Eclipse Plug-In by Cameron Purdy on June 14 2006 19:59 EDT
- Yes but what about the line numbers by Peter Kelley on June 14 2006 21:34 EDT
Since this happens to be a favorite topic of mine: 1) I like the idea (it sounds kind of like Microsoft Word commenting and revision tracking), although I think that the #1 tool for getting peer reviews to work is the LCD projector and a big white screen. 2) Obviously, if quality truly mattered, then they'd be using IntelliJ and not Eclipse, so where is the IntelliJ plug-in? ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
We have tried to use Jupiter for our code reviews but there is one major issue with it that makes it virtually unusable. All of the review annotations are tied to line numbers which means that when a developer fixes an issue and adds or removes lines the review annotations no longer point to the correct location. This is a major flaw IMHO but I'm not familiar enough with Eclipse plugin development to know if annotations can be tied to locations in the code independant of line numbers to fix the issue.
We have tried to use Jupiter for our code reviews but there is one major issue with it that makes it virtually unusable.While it might not meet Cameron's #2 criteria :), Netbeans Collaboration Project seems very interesting. http://collab.netbeans.org/ I have not looked at it in 6 months, but we could only seem to get it to work with Sun's IM server.
For completeness, there is the Eclipse ECF project too. Now if I just had a team to work with .... .
We have tried to use Jupiter for our code reviews but there is one major issue with it that makes it virtually unusable.
While it might not meet Cameron's #2 criteria :), Netbeans Collaboration Project seems very interesting.
I have not looked at it in 6 months, but we could only seem to get it to work with Sun's IM server.
In my experience, it works OK within Eclipse (issues move with the code when you edit the code, just like Checkstyle issues or syntax errors), but it gets confused if files get merged by the SCM tool, or if the review files are not committed to SCM at the same time as the source code files. I've asked the plug-in authors to comment on this point. Cheers, John Smart http://www.wakaleo.com