The full impact of software engineering has not truly been gauged until now. It's multiple belts up from the white-belt WattDepot katas we previously tackled. It's the combination of our basic skills with WattDepot, our fleeting glimpse of Continuous Integration (CI), and our whirlwind introduction to Issue Driven Project Management (IDPM). And the most lethal ingredient of them all is teamwork, as implied by CI and IDPM. Lethal, but unavoidable. When working with others on a project, CI makes things a bit easier by assuring project team members that the system they are developing is in working condition at all times. The status of verification of the build is automated under a CI server such as Jenkins, which triggers an automatic verify test on the system in the event that a team member has recently committed changes to a Subversion (SVN) repository such as one hosted by Google Project Hosting. CI also requires team members to commit regularly, such as at least once every two days. Meanwhile, IDPM is designed to keep all project team members on task at all times by associating each task with a specific issue at hand, and ideally, issues should not take longer than a few days to complete. Successful IDPM requires frequent group interaction, always having another issue at hand after completing one, and general knowledge of where the project is headed at all times. In particular, Google Project Hosting (along with SVN and Jenkins) was used to drive IDPM; there, it is easy to see what tasks are (mainly, among other statuses) Accepted, Started, and Done by opening all issues under Grid view.
The project, which can be found at this website, was to create a command line interface program to understand various aspects of energy use in the Hale Aloha Towers (freshman dorms) of the University of Hawaii at Manoa. My team in particular consists of two other members. As in the real world, we did not get to choose who to work with. We had to choose a name for our team and, after mulling over a brainstorm-generated list, settled for "Pichu" (not necessarily after the Pokemon of the same name). We exchanged phone numbers and Skype usernames and had the project broken down into the important issues at hand, all in the first day the project was assigned to us.
Mentioned above, the dynamic trio of Google Project Hosting, SVN, and Jenkins was used to drive IDPM. Before each commit I made (except for one or a few times in which case I was positive the program would pass verify - but alas, lesson learned: never assume), I made sure to run verify on the system. Then, after a commit, I would check the associated Jenkins job to make sure that it built the system successfully. To address IDPM, after the disastrous surprise in-progress technical review, I made sure to associate each and every commit (known as a revision in Google Project Hosting) with the issues I addressed. To take it a step further, when I updated the issues themselves, I added links to the revisions that handled these issues.
Our team originally had the issues all planned out from the beginning, but as we finished our main issues, if we thought up more issues, those were simply added to the existing pool of issues. Because of IDPM and overall constant communication, we were able to gauge what everyone else was doing and hence finish the project in time. The basic program functionality has six commands; a description of each can be found on Team Pichu's home page. There were four main components to the program, namely: the Main class, the Processor class, classes that implement the Command interface, and JUnit test classes. Main contains the driver for the program, establishes connection to the WattDepot server, and creates instances of the Processor class for each command or invalid input entered by the user. Processor takes the input, parses it, and determines which Command-type class to call based upon the input; if an error arises with the input, then Processor returns the appropriate error message to Main. Each Command-type class must implement the Command interface's run, getOutput, and getHelp methods; in addition, each Command-type class should have a default constructor (in addition to constructors with parameters, if any). If the Command-type class takes one or more parameters to the constructor, then that constructor should throw an IllegalArgumentsException, and a checkArgs method should also be implemented. Lastly, each Command-type class should have an associated JUnit test class (Main and Processor have test classes as well).
Unfortunately, we were not able to implement Java Reflection, so most of the code is hardcoded. For example, if a Command-type class is added to the Command package, then changes to Processor and Help need to be made, and a corresponding JUnit test class needs to be created in the Test package. Hence, decreasing the number of places that code needs to be updated any time a new command or feature is added to the program is a future improvement that could be made. Overall, this experience has been completely meaningful and worthwhile because of the real-world experience of working with others in real-time to produce a single smooth and functioning program. Communication, which could certainly have been better, was definitely the key element to success, as well as consistently working on the project over a long period of time. I felt that both communication and consistency were quite challenging when one is out of sync with the other. Without constant feedback through communication, it becomes more difficult to gauge what each team member should be working on. Another critical learning experience is what to do in the unexpected event of some greater force negatively impacting the project at hand. The WattDepot server had crashed and there was a hard disk failure for the first time in about four years. Luckily, our group was able to step up to the plate and align our project with the newfound situation at hand. In conclusion, I feel that IDPM is much more difficult than it had first seemed; moreover, the overall quality of our software could have been better and less hardcoded.
No comments:
Post a Comment