DueDates Project Review (Part 2)

Premise:
In this third increment of our DueDates project, we've been given the chance once again to review and get reviewed by our fellow colleagues for this application. Along the way I'll also explain about my experiences gained from this review and during this past week.

GPH Review:
We've managed to, at this point, do everything through Google's Project Hosting (GPH) site. Again, Google has given us the tools to code effectively in a real world environment setting. If you navigate over to the source of any project (that's hosted by GPH) there will be a new featured link next to the "search trunk" called "Request code review." The new feature makes it easy to request a code review amongst your team members or outside code reviewers. You are able to note a description of the review, branch path, marked issue status, and labels.
Overall the reviews from team duedates-red were positive and fairly short. There were still a few things we needed to provide to accompany our code, such as our wiki's. We've managed to well document our code in JavaDocs but have yet to utilize the GPH's homepage and wiki's features. Hopefully by the end of this review, we'll have a better and more concise explaination of our project on our project's homepage.

A positive experience:
In this third increment of our Duedates implementation, we've gotten a chance to better understand the structure and hierarchy of our program. Though it was difficult to grasp a clear plan in the beginning, we began to see the path lit up as the programming process progressed. It became much more beneficial to use programs beyond the use of Eclipse and quality assurance tools. Personally, I resorted to using a modeled approach to plan out our class structure. If anyone owns a mac or just wants to learn more about mac software, then I would recommend something called OmniGraffle. It is almost like Microsoft's Visio, but for the mac. After experiencing this newfound tool, I've come to realize the power of organizing my ideas, in a sense, on "paper". The program also gave me the ability to quickly implement an idea, and if i decide that the idea blows or doesn't live up to the overall design, then I could simply discard it and update my program in the same matter. This helped me develop a sense of awareness of the project's path and direction and it even provided me a clearer perspective in coordinating myself in a project like this. It also coerced me to program in a TDD fashion. Speaking of TDD, I became very TDD this past weekend. I actually got reacquainted with two very familiar friends, JUnit and EMMA. Yes, can you believe it? I actually used EMMA! EMMA proved to be very helpful in cases where I needed to better sculpt the usefulness of some functionality. Maybe a statement that wasn't being tested via JUnit, really turns out to be unnecessary for the overall application. I questioned that to myself when I had a low percent coverage. Could this mean i could do just the same amount of work with less code and more coverage. Well in some cases, yes! You can pick out certain things that can't be detected by other QA tools, because EMMA forces you to review those statements you think are needed to test the overall application. If you look deeper, then you'll see that maybe sometimes it's best to not even have that subject there in the first place. JUnit on the otherhand would not tell you that you need a test case for missing arguments. So the marriage of JUnit and Emma makes a good team in assuring better quality and sensible units of code.

Conclusion:
After taking this time to review other projects and assessing our own, I have gained new knowledge in the process of developing in a test driven environment. I have also gained the ability to strengthen my overall model (class) organization and program structure.