Eyes on the Code: Reviewing WattDepot-Cli Branches

We finished and put up our version 1 of our WattDepot-Cli and without delay the next task is in our hands, Peer Review. Whether it’s for writing, foreign language, or even software programming, peer review can be one of the most difficult and yet beneficial forms of review one can have. Peers often know what the other person is thinking, and in general will have a nicer perspective to your work (no yelling about incorrectness or error) simply because they are controlling the outcome of the project directly. This week our task set out was to evaluate two other groups from our Software Engineering class to see what they did good and what they could improve on for the upcoming version 2 upgrade.

For the review we were assigned two other groups in our class and asked to put their code, builds, and methods to the test to see if they could stand up to being the interface we wanted to create. Given the template (provided here) we were asked to evaluate the functionality, documentation, readability, and testing of the projects. It wasn’t just a simple pass through verify.build.xml (the keeper of junit, checkstyle, pmd, and findbugs) but also a check for us to look over other’s code and give feedback.

The full review can be found here for the two groups:
Ekahi

Umikumalua

I cannot say that I am the best tester in the world (and honestly I will explain my troubles with testing other peoples programs in my own response to this soon), but knowing that we all need to help each other out I did a basic overview of the systems.

Ekahi
The Ekahi team had most of their methods done and functional and a very tight control over most of their input (only one major error in input was found when I was looking through the code). Overall the code works to a specification and is not bad. The trouble with Ekahi lied in the lack of testing which actually put the code to the test and the use of methods which did not return values but rather simply printed values on the screen. This form makes it a bit difficult to test and also is not one of the ways that we were guided to take. If the team can work out those issues then it would be a great piece of work.

Umikumalua
The Umikumalua team feels a bit rougher in terms of how much of their work felt solid. The command interface worked when given things that were designed to work, but handled error rather randomly, catching certain issues ok but also faulting when not enough parameters are given. It is a major problem that needs fixing and it is my belief that an overhaul of the system to follow Johnson’s approach (mentioned in my last entry) could help alleviate some of the errors. The consistency of the files was a little more noticeable as well as the naming convention issue. The program also needed to include tests to help alleviate any problem holes that may be in the program that I might not have caught. Overall though the potential of the program is there and the major issue is completing the program to specifications and following a form that uses returns to give information. A bit more time to work on the project and its possible to have a fully working project with most of the errors fixed.

I must say that while I did look through the code a lot of what could be issues might have slipped through my fingers, though in the end I hope what I did find can be useful to the user/developers/students and help them design a better system. A reflection of my own views and my own reviews later on may shed some light on how this form of testing works with my own personal style, both of writing and reading code.