Teams Performance

For these past few weeks I was in a group implementing a console base program to retrieve data from the Hale Aloha dorms at UH. It was a great experience working in a group because not only have I learned new skills in Java coding, but also learned to communicate with people; more information can be found at this post Pichu.

This time my group members and I have a chance to review another group’s project which behaves same as ours when user inputs a command and parameters, but differently in error handling. The project we had to review had a simple name of just “teams”. Their program had the following features:

·   Current power – retrieves the current power consumption of a tower

·   Daily energy – retrieves energy consumption of a tower from a particular day

·   Energy since – retrieves energy consumption from a range of days (e.g. 2011-11-23 to

    2011-11-25)

·   Rank towers – ranks each tower’s energy consumption from least to greatest and display data in a list

Before I get into talking about the features and defects about this project I would like to talked about where my group members and I obtained the project from. This project was obtained from this website, http://code.google.com/p/hale-aloha-cli-teams/, on the first click I of the link I was redirected to their introduction page and first thing I see is a brief explanation of what the program is and the features, mentioned earlier, being supported. It was simple enough to understand what the program does, but it would be an enhancement to show an image of how the program would look like after the user installs it and uses it. Otherwise their Wiki pages are very well written that I can follow the steps of how to install the program and run the program, which is to just download it and then invoke java –jar hale-aloha-cli-teams.jar.

            Feature wise it is pretty well featured with the commands in this current version of the program. The help feature was pretty useful to give descriptions of what each command does and what input it accepts to retrieve information from the server. During testing I did had parts where I forgot what a certain command accepts for input, with the help feature I was able to accomplish it in no time. The messages returned for each command after the data has been retrieved were pretty informative. For example, one of the commands I entered is as follows: current-power Mokihana and it returned the following message “Mokihana’s power as of 2011-11-30 6:52:40 was 31.1 kW. The message is not too long, but simple and straight to the point of what I should expect when I invoked the command. Here’s a picture of what messages are printed for the other commands.

           

 Although, the features and data messages are good and informative, but the error messages being returned isn’t as informative as I (or my group members) expected. For example, I deliberately typed in the following: daily-energy Mokihana 2012-11-23 and the error message returned was “For input string: “Error: An error occurred in the XML from the server”. At least the error was caught and a message is shown, but it doesn’t relate to what the error really is. What if an user haven’t heard of what XML is, then this message would be confusing to that particular user. It would be better to have the message indicate the date is too far in the future or something. Practically, the same message was printed out for incorrect date entry for other commands as well. However, it does show this team was trying to be consistent with the error messages for the same type of input error.

Reviewing a program by just installing and executing it alone is not enough to tell if the code is well written. Another part in reviewing a program is to actually view the source code(s). Before I get to review this team’s code, the initial part is to read up their Javadocs. I was able to build the Javadocs by using the ant –f javadoc.build.xml. This will create a directory call javadoc (located in the build directory) which contains all of the html files that we can access to view the Javadocs of this project. Their Javadocs are pretty consistent with the method names. In the methods that retrieve data for each command they have their method name as getData follow by a description of what it does base on the command. They did follow the rule to comment their comments so we know what they are doing.

After reviewing their Javadocs it’s time to talk about their source code. Their code did follow the rules in Elements of Java Style such as commenting their code, use of verbs to name a method that does some kind of action and many more. Although, their code did pass the test of CheckStyle, PMD, and FindBugs, but there are some parts that aren’t errors but more associated with bad style. In their method call help() they were printing the messages with System.out.println() and some had the .println part skipped to a new line (see snippet of code below)

They could’ve completed the System.out.println() and then concatenate at certain parts of the string to meet the requirement of no more than 100 characters per line. Also, in the class call ManualTestProcessor there were some redundant comments. The parts of code is already described of what it does with the System.out.println() line of code. An example would be as follows

   To conclude, this project did meet the requirements of the Three Prime Directives which is the system accomplishes a useful task, user successfully installs the system, and external developer is able to understand and enhance the system. Due to the well commented code it was easy to understand what each class performs. Besides some bad styles and some message problems from invalid input, this program does what it is suppose to do. If it has a chance to become a real software product this would be a successful and easy to use product to let user monitor their energy consumption.