After working with Scheller Sanchez on the first release of Due Dates, I was ready to take the next step in expanding and enhancing the overall system. Since it is still in the first version, Due Dates is far from being a perfect system. There are many things to improve on and a lot of things to extend the program to. Many times, an efficient way of evaluating everything is by performing a series of reviews on the program, pointing out what does not meet requirements and what design features could be improved.
Doing Reviews
I participated in three reviews - one for duedates-blue, one for duedates-orange, and one for duedates-green. I found this to be a really insightful experience. As Scheller and I designed the structure for duedates-gold, we often wondered how other teams were laying out their system. I personally really wanted to see how far other teams were taking it. By doing these reviews, I got to see just that.
It was really interesting to see how teams structured their systems. To see certain functions - like the program menu function in duedates-blue - actually implemented was extremely useful. I personally had been thinking about implementing that sort of function on our version of Due Dates. Now, I can better judge the use of a program menu in our version. Another thing that intrigued me was seeing how different groups did different things. For instance, one of the groups I reviewed had large amounts of code for parsing the command-line input. Another group had a relatively small amount of code for this, yet surprisingly they did basically the same thing.
For some of the teams I reviewed, it was easier to pick things out to comment on, and for some teams it was a bit harder. Nevertheless, I found some overall problems I'm sure others had found as well. One of these things was Exception handling. Every project I reviewed just showed a stack dump upon exception. This is not good.
Receiving Reviews
The Due Dates - Gold system was reviewed by:
- erinjuneilkim
- creightonokada
- aricwest
- jnancheta
- anthony.m.du
- john.km.zhou
What was cool about all this was that even though Scheller and I specified specific things for each member to look at on our Review.wiki page (documentation, testing, class structure, etc), most of them went out of their way to inspect some of the other code as well. We got a lot of great feedback, good and bad, about our program design and how are program fairs in general. I was surprised to see comments about things I would have totally missed on my own. A good example of this is the command line program requirements. Scheller and I both forgot to integrate the -uhm command in our program but luckily Aric West commented about it.
I am usually really strict about how I program things. However, I do let things slide from time to time and I forget about them. It really is great to get an outsiders perspective on the internals of the program. Having these reviews done on our program can only improve what the future system will become.
Problems with Google Project Hosting's Review Tool
I couldn't believe how many problems I ran into using Google's built in review tool. As a reviewer, my main problem was publishing my so-called 'draft comments.' Half the time there was not a 'publish your comments' link on the page and I was left stuck, wondering what to do. On the first review I did, this occurred and I navigated back a few pages to see what would happen. Somehow by doing this I lost all my draft comments and I had to re-do them. After that instance, when there was no publish link, I realized the only way to fix it was to navigate to different pages until one did pop up. This actually worked well since my comments didn't disappear anymore, but it was a real hassle at first.
I also had big problems trying to see the comments that were left on our source code. This is actually something I'm still trying to figure out! It seems like only some of the comments made actually show up when you browse to the file, and others are left hidden. All six reviewers did post reviews, but they didn't all show up together. When I first looked at the source code, there were only reviews from anthony.m.du, john.km.zhou, and aricwest. In addition, these reviews were sometimes there and sometimes not there. It was really confusing! The way I found the other reviewer's comments was through a link in one of the gmail notifications, of which I only received for two reviews. This link brought me to some other page that listed all the comments on their own. What's better is that aricwest's comments were on both the source code side and the comment page. I have no idea why it does this but I'm just glad I figured out a way to see them all.
What I learned from it all
After doing reviews, receiving reviews, and dealing with Google's review tools, I can now see the importance of a software review. For the past week I have been trying to think of ways to improve the structure of Due Dates gold. Now I think I have a better idea of what needs to be done. The reviewers of our code really help in creating a better system overall.
Posts
0 comments:
Post a Comment