Practicing Software Review

Part of learning to become a good programmer is reading other people's code and having other people read your code. The DueDates project that everyone in my ICS 413 class is working on presented the perfect opportunity for us to practice reviewing each other's code. Since we are all working on (our own versions) of the same project, we all already have some baseline understanding of each other's code, and anything we learn from each other can immediately be applied to improve our own project.

Reviewing Other Code

I reviewed the projects of Team Purple, Team Red, and Team Violet. At first, I was a bit hesitant to comment on their programs--after all, I don't know anything more than they do, so who am I to be making suggestions? I tried to find intelligent, constructive things to say, but generally, their code was fine, and for the most part I was only able to find relatively minor points to discuss. Reviewing their projects was probably more helpful for me than it was for them. In particular, I learned from reading Team Purple's code how to use the Exception.printStackTrace method to suppress the stack dump and only print out the error messages. I also got some ideas on how to better test our system by looking at their test cases.

Reading Our Reviews

Daniel Arakaki, Yasu Kaneshige, Vincent Leung, John Ly, Robin Raqueno and Tyler Wolff reviewed our (Erin and my) project. Many of their comments addressed issues that we were already aware of, but just had not had the chance to implement or fix yet. However, some of their comments provided points of view that I had not considered. For example, John Ly pointed out that login credentials are properties of users, not libraries, so they don't really belong in our library classes. Because objects in a system are so inter-related, I often have trouble deciding what belongs in one object and what belongs in another, so I found this comment quite helpful.

Trouble with Google Code Project Hosting

I experienced many problems using Google's code review system. First, after I added line-by-line comments, most of the time the option to publish my comments did not appear.


I had to navigate away to a different section and then come back in order to be able to publish my comments. Unfortunately, after returning to the page, my comments were no longer visible.


Even after publishing my comments, I was usually not able to view them by browsing the source file. In addition, there were two occasions where, upon returning to the page where I commented, my comments no longer existed and I had to recreate them. There was also at least one instance where, when I tried to publish my comment, Google Code only gave me the option to publish a previous comment that I had already published, not the new comment. Finally, there was one case where I thought I published a comment (for Team Red) and everything seemed fine, but then I found out later that my comment was never actually published! Overall, using Google Code Project Hosting's code review system was very frustrating.

For Next Time

Many of the reviews of our project commented on issues that we were already aware of. Also, many of the reviewers commented on the same small set of issues. I had thought that, because our project was so small, the reviewers would look at the entire system and find different things to comment on. In the future, I think it would be more helpful to use if, during the planning/orientation phase of the software review, I think we should define more clearly the different aspects of the system that each reviewer should examine. That way, we hopefully get a more thorough review of our system.