Reviewing Code in Eclipse with Collaborator
Collaborator has a fully-featured Eclipse plug-in that lets you upload changes to be reviewed. It also supports a complete end-to-end workflow in Eclipse. This deep integration with the IDE lets us provide some great features to users that are simply not possible in a Web UI.
This blog post is going to gloss over the various ways you can upload changes to be reviewed from within Eclipse and focus on performing the review within the Eclipse IDE. After the author uploads the files and starts the review, our plug-in decorates the files currently under review with a green checkmark in the various Eclipse file views.
Reviewers receive an email inviting them to perform the review and the review is listed in their Action Items View.
Double-clicking on a review in the Action Items list opens in the Review Editor. This editor provides all the same core functionality as the Review Summary page of our Web UI, but with Eclipse UI metaphors. In the Review Editor you can edit the properties and custom fields of the review, add and remove participants, see the list of all defects in the review, read and add comments and defects about the review as a whole, see the list of files in the review and a summary of the status of each conversation on those files and, finally, indicate that you are done with the current phase of the review.
Clicking on a file listed in the Review Editor opens up the Eclipse Compare Editor showing the diffs of that file added to the review. We take advantage of Eclipse’s built-in Compare Editor, which knows how to syntax highlight various programming languages, show structural comparisons of the file (e.g. which methods in a class were modified), and has various options like showing whitespace, synchronized scrolling, etc. Our plug-in adds functionality for creating comments and defects at different locations within the file, and for selecting which of the versions of the file in the review you want to compare.
Let’s say the reviewer identifies a defect in the file that they want the author to fix. They add the defect in the Compare Editor and then close it. In the Review Editor they click “Finished,” sending the review back to the author in the “Rework” phase. The author will get an email and the review will be highlighted in their Action Items View. When the author double-clicks on the Action Item we open the Review Editor to show them the status of the review. Clicking on the defect opens the Compare Editor on that file and focuses on the line with the defect.
This is the place where our Eclipse plug-in really provides added value above and beyond what we can do with our Web UI. The author can go to the version-select drop-down menu and select “Local File.” This opens a comparison between the content of the file currently on the user’s machine and the version in review.
The user can then use all of the code navigation features built in to Eclipse, e.g. control-clicking to follow a method call or variable definition. The author can also edit the file right there in the context of the review in order to fix the defect identified by the Reviewer.
If they prefer, of course, the user can alternately use a regular Eclipse editor to edit the file. Even in regular Eclipse editors we provide an error marker on the line in the file that has the defect in the review. These markers show up in editors and also in the Eclipse Problems View the same as e.g. compilation errors. The user can filter what markers they want displayed (e.g. show open defects, hide closed ones) and control how Eclipse interprets the severity of those markers.
This kind of tight integration between the user’s development tools and our review tool is only possible with our Eclipse plug-in; it simply isn’t technically feasible with just our Web UI. For Eclipse users, this provides a great workflow. They never have to leave the environment they’re comfortable with, and there’s no need to pay the penalty of context-switching to a new UI.