Frockle/PeerReview
Introduction
The peer review exercise includes a physical meeting at Bolton University on 25th April, but entails some preliminary work beforehand. This year, rather than perform the exercise in mutually reviewing pairs, it is actually a triangular round-robin where each team reviews the work of another, within a triplet. We are reviewing the work of DesignShare. In turn, we are being reviewed by ResourceBrowser.
General Observations
Whilst the peer-review exercise entails reviewing one project in particular, there were a few general points I thought were worth making when I was bookmarking sites the other day.
Blogs
- If the institution hosts a blogging service then it is great to use this, as you (often) get the benefit of institutional branding.
It is easy to create a blog using a third-party hosting service, see Blogger, Wordpress, Typepad, etc. Many support the notion of having more than one author (e.g. Blogger).
- Having an RSS feed from your blog is a great feature to enable interested parties to keep up with your posts. Again, by using a well-known blogging service (see above point) you will almost undoubtedly get this for free.
Main Exercise: DesignShare (conducted on April 24th 2007)
Pluses
Good project web-site which provides a nice introduction.
- Sensible code formatting and comments.
Being built as an Eclipse plugin, so effectively a standard build procedure (no scripts required) and then just Run As -> Eclipse Application to execute it.
Software works "out-of-the-box"! Compiles and runs from a CVS check-out. It is true that this reviewer [AO'C] has had some familiarity with building Reload before (for which this project is a plug-in) and a superficial understanding of Eclipse plugins, but it goes to show that if you write against a standard framework (Reload / Eclipse) you can "get away" without having any documentation
.
Minuses
- Could not find a project blog.
All the CVS commit messages are blank - helpful to have a bit more information, even if it's just "Added a bit more code ..."
. License is probably in the wrong place - should probably be placed at the top of the file above the package declaration.
A lot of object-oriented GUI programming involves subclassing and overriding of (callback) methods. Therefore, as the javadoc tool copies entries for overridden methods from the superclass, it is not necessary to document these methods (unless they deliberately deviate from the expected behaviour !). Or, put another way, document the private methods which these callback methods call / do the actual work.