In my latest experience, I got to know how to work in a completely new environment-- that is, working with others rather than by myself, which I have been more-or-less doing up until now. Now, you may think, "what's the big deal with working with others? People do that all the time, even with computer-based projects." This is very true, but the question is, "are they doing it correctly?"-- as in effectively and efficiently. They may, or they may not be, but I definitely received an exposure to a great process collaborate as a team on a project involving continuously-changing code, as well as an efficient way to utilize it. The process is called Continuous Integration, and the way to use it is through Issue-Driven Project Management.
Basically, Continuous Integration (CI) keeps all the group members up-to-date on the status of the project, notifying members immediately when something is "broken", and when it is "fixed". Issue-Driven Project Management (IDPM) is exactly what it says-- it's a system for managing a project by utilizing "issues". Issues are tasks set up by project members for designated members in order to 1) make sure that members aren't going, "uhhh, what should I work on now?", 2) make sure that members aren't working on the same part of the project at the same time, and 3) keep track of who did what. For our project, we used a combination of SVN + Jenkins (CI) and Google Project Hosting (IDPM) to create a project where we implement the WattDepot application-- the same one I introduced to you last time with my WattDepot Katas.
One thing that was very nice about using Continuous Integration and Google Project Hosting was the sharing of wealth; group members could work on portions of the project that were in their respective areas of expertise, or could even help fix something that another member broke, helping that person to understand the problem and become a better programmer.
On the other hand, having multiple people work on the same project has its downsides, especially when it comes to consistency. One person's thought-process, style, and knowledge is different from another's, and the same thing can be said about coding. No two people code in exactly the same way. So while I used Regular Expressions to check if a date was valid, another person used Lists and String matching to verify the location specified. Neither of us is more correct (although speed, code-length, and accuracy might differ), and so it was extremely difficult to resist the temptation to try and correct someone else's program and adjust it to fit your own coding styles.
But overall, we were able to work together with this framework and complete this project successfully. Our product is a command line interface program that users can use to view various data from the Hale Aloha residence halls at the University of Hawaii. For now, there are 4 basic functions to view the data for-- Current Power, Daily Energy, Energy Since, and Rank Towers, but the system can easily be expanded to accommodate more in the future. Entering "current-power " and a tower name will output the latest power readings for that tower. Entering "daily-energy [tower] [yyyy-mm-dd]" (without brackets, and where yyyy-mm-dd is a date) will give the energy consumption for the specified tower on the specified day. Similarly, "energy-since [tower] [yyyy-mm-dd]" will output the energy consumption for the specified tower, but as the total consumption from the specified date until the current time. Finally, entering "rank-towers [yyyy-mm-dd] [yyyy-mm-dd]" will output a list of all the towers sorted by their total energy consumption for the interval given. Additionally, the command line interface program supports the commands "help", which lists and explains the available commands to use, as well as "quit", which is used to exit out of the program. Until the user enters "quit", the program remains in a loop, so you can keep running commands and viewing data to your heart's content.
I believe that while far from perfect, our project turned out to be one of rather high quality. Perhaps we could've structured it differently to allow for better testing, or enhanced it to make it more robust, but it does what it needs to, and is fully functional. Because we got to share our knowledge, we got to see various new methods of accomplishing certain tasks and use those techniques in our own components of the project, rather than using the same old sub-optimal ones that we have been using for the longest time. There are always challenges with working in groups, but in the end, if there are even just a few parts which turned out to be implemented in a better way due to the collaborative efforts for everyone in the group, then I think the project is successful because each member takes away something learned, and can apply it with future projects.
No comments:
Post a Comment