RFE: peer review engine

Jason Boehle wrote:

Many developers out there these days either are forced to, or
voluntarily, do peer code reviews.

A) One shouldn't check changes into one's VCS system until you've had
your code review.
B) No easy way to keep documentation on what was code reviewed, what

> the reviewer's comments/suggestions were,

C) Configurable workflow definition for review process.

Interesting points - but is this really an existing problem?

I mean, from a personal perspective:

A: Code reviews don't happen on checkins, but at much larger (monthly)
intervals, and span much more code than my personal checkins. For me,
having a review for every checkin (and having to do a review for every
checkin by someone else) would completely destroy productivity.

B: As far as I can tell, checkin & codecomments will do nicely for this.

C: I definitely don't want that in my IDE - I've suffered through
the bondage-and-domination school of development tools (VisualAge, and
to a lesser extent ClearCase & WSAD/Eclipse) that try to impose a
'workflow'.
My experience is that if you try to impose something like that people
work around it anyway, causing more work than the problem you were
trying to solve in the first place.

Cenqua Crucible: http://www.cenqua.com - won't be out until next
year. Jupiter Eclipse Plugin:
http://csdl.ics.hawaii.edu/Tools/Jupiter/

Cenqua seems to me more of a bugzilla-like tool: tracking history. That
makes sense (although I still feel they are trying to solve a problem
that doesn't exist...)
The Jupiter thing seems more of mix of 'annotations on steroids'
and 'todo/tasklist'. I don't see why this cannot be solved in the
sourcecode (possibly with new javadoc tags/jdk5 annotations).
Introducting g yet another set of artifacts with all the problems of
keeping this in synch (no matter how nicely integrated with you IDE -
it's still a separate set of artifacts) seems a recipy for mayhem.

The way I deal with this is simple - comments in the code. My code is
full of 'FIXME' 'CHECKME' stuff. The way IDEA (and WSAD/Eclipse) extract
this info into a 'tasklist' is exactly what I need.

Just my 2cts. ;)

CU,
Edwin

Way more useful would be a way for two people to work together on the same editor. Think about "remote pair programming". There's an eclipse plugin for this:

http://sangam.sourceforge.net/oldsite/

(Liked to the 'old site' because the new one is fugly)

-1

Sorry, but this doesn't have a place in my world. I ask for paper when
I'm reviewing someone's code. This allows me to put comments. Some are
"must change", others are "Here's an Idea (sic)" or "Keep this in
mind". Where applicable, I will also jot down code as an example. To
do this right, there is a huge infrastructure that needs to be behind it.

However, it seems like it belongs in a separate product. Unfortunately,
I doubt that is much of a market.

Jason Boehle wrote:

>Many developers out there these days either are forced to, or voluntarily, do peer code reviews. The biggest problems that the peer code review process faces, IMO, are:
>
>A) One shouldn't check changes into one's VCS system until you've had your code review. The easiest way to do this is to grab someone and have them review your changes right before you check them in. But what if that person is busy? What if you need to get onto other things? What if that person is somewhere else in the world?
>B) No easy way to keep documentation on what was code reviewed, what the reviewer's comments/suggestions were, or what the reviewee did about it. This information can be useful to both developers and management in various ways.
>C) Configurable workflow definition for review process. If manual, "grab a peer" reviews are done, everyone does a review in their own way. As a project grows, the list of things to make sure new/revised code does increases, and it's sometimes hard to make sure you cover everything in a code review.
>
>There look to be a couple of things out there that try to address this problem:
>Cenqua Crucible: http://www.cenqua.com - won't be out until next year. No demo or beta available as of yet.
>Jupiter Eclipse Plugin: http://csdl.ics.hawaii.edu/Tools/Jupiter/ - haven't tried it as I don't use Eclipse.
>
>Are there any other tools out there that I don't know about?
>
>The whole point of this thread is that I would love to see something like this integrated into Idea. It seems that XP (eXtreme Programming) is taking hold at more and more places, and peer code reviews are more and more becoming a requirement of our daily lives as software developers. This could be a killer feature for Idea that would differentiate it from it's competitors even further.
>
>I'd love to hear what other people think about this issue.
>
>-Jason

>

Ah, a new release plan coming out soon, and thoughts turn to adding teamware to IDEA. Probably a sign that the product is reaching the point of diminishing returns at the task of supporting individual developers coding Java. IDEA just can't get that much better without expanding the scope, either to support more technologies or to suuport teams.

I agree that there's value to be had in supporting the code review task, but before adding some complex annotation/workflow superstructure or issue tracking integration or some complicated and undoubtedly flaky remote editor-sharing thingy, there's room for improvement on fundamentals.

1)Directory diff. The only reason I use BeyondCompare anymore is because it supports directory compares and IDEA doesn't. Adding directory diff would allow me to simplify a lot of my personal workflows.

2)Workspaces. Let me create and manage sets of files on a per-task basis. Chris Bartley's plugin is a start, but the workspace concept really needs to be a first class citizen in IDEA. There are probably at least thirty actions which would need to be supported for file sets, and the existing plugin does maybe four of them. I want to see "Create workspace from changed files", "Show workspace diff", "Commit workspace", "Check workspace CVS status", "Run inspections for workspace", "Search in workspace", "Run JUnit testcases in workspace", etc. etc. On products that have already shipped at least once, most changes should be in response to a task, and file changes reviewed and checked-in on a per-task basis. This could be huge, and the scary thing is all of the logic may already be in the product. Take the

3)Sharable error-checking profiles, selectable on a per-project basis. Because teams mean standards, and quality standards are probably the most important.

Give me those, and then it might be worth thinking about blazing new trails in IDE teamware for peer review. No use thinking about what the house should look like if we don't have the bricks to build it with.

--Dave Griffith

Whoops, just realized I posted too early. Re: Workspaces

"This could be huge, and the scary thing is all of the logic may already be in the product. Take the named search scope stuff, rename it workspaces, scatter some UI for accessing it around the application, and ship."

--Dave Griffith

Dave Griffith wrote:

workspace", etc. etc. On products that have already shipped at least
once, most changes should be in response to a task, and file changes
reviewed and checked-in on a per-task basis. This could be huge, and
the scary thing is all of the logic may already be in the product.

99% of the changes that I make are in response to a Problem Report that
has been filed and assigned to me (new features as well as bugs are
filed as PRs). All CVS commits related to a PR must have a message
starting with a line which identifies the PR so that the commits can be
associated with the PR for tracking purposes. I would like to see the
workspaces idea provide some means of associating a PR identifier with
the workspace and optionally prefixing the messages of all commits of
that workspace with a template which can reference that associated PR
identifier.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

I think this would be cool. Sort of like pair programming, but not at the same desk.

SubEthaEdit is a text editor that has a nice implementation and UI for this. (Mac OS X only)
http://www.codingmonkeys.de/subethaedit/
http://www.codingmonkeys.de/subethaedit/screenshots.html

They use rendezvous/zeroconf for their networking. Fortunately, apple just provided open source windows and unix ports.
http://developer.apple.com/macosx/rendezvous/

I could see several people editing the same file, and going through a merge step an any given point (right-click, accept change, or even a merge panel).

--pete

+1 to workspaces.

Dave, please submit this into Tracker - it's exactly what I'd like in IDEA 5.0.

Inigo

There's been a workspaces request open since back in the old Ariadna days, although I can't seem to find it in Tracker. Chris Bartley's excellent plugin took some of the urgency off it, but there's a lot of room for expanding the concept.

--Dave Griffith