I recently extended a project I hadn't written, adding a few more features to it. I worked collaboratively with 2 other people using the IDPM (Issue Driven project Management) process. The three of us divided our task into more or less equal parts, and went about adding the desired functionality to the system. The system is a power an energy monitoring platform, and the functionality we added provides commands to set baseline, goals, and monitoring of those goals in terms of power and energy consumption.
During the entire development process, I was lucky enough to never once have a source repository merge conflict with any of my partners' code. I guess we all knew how to say out of each other's way, using package names and classes and encapsulation and separation mechanisms to make the code modular and flexible.
But the thing that most simplified our task was the build system infrastructure included with the system. It took care of dependency downloading, compilation, deployment, testing, automated quality assurance, and more. I'm talking about the Ant build system, which along with Maven, is the most used in the Java community and works very well with Java and its tools. The project came with a complete and modular Ant build specification, constituting about 10 Ant files (which are XML files using the tags in the Ant namespace), so that we were able to get off the ground and running within seconds of downloading it.
We did have to meet a few times though to sort out external interfaces and dependency issues, like what modules depended on what modules, and therefore which modules needed to be completed first. At our meetings we quickly got down to specifics and used an eraser board to write down pseudo-code, interfaces, and object definitions. One of my partners even took a cell phone snapshot of the eraser board for future reference.
Possibly even as useful as the automated build system was the continuous integration process we used to develop the system enhancements, a combination of the Jenkins build system and the google Subversion project hosting. Had we ever run into compilation or testing problems, we could have easily known who was responsible and could have easily rolled back the system to a previous healthy state if the problem could not be fixed.
The combination of automatic building, continuous integration, and automated quality assurance kept or code honest and its format uniform. One thing I found about working with quality assurance tools like Checkstyle, PMD and Findbugs, is that they frequently teach you about writing better, more effective and more correct, code. Many of the tips and suggestions included in books like "Effective Java" by Joshua Bloch will show up as warnings in PMD and Findbugs. It's great to have them there to remind you of when you're doing something unsound.
The whole process went so well, that I don't think we had a single failed build on the Jenkins server. Of course, I know that this implies that each one of us must have been running their Ant verify script locally every time before checking new code or configuration changes into the system. I know, that I can rarely make any change of more than a few lines to the system without Checkstyle, PMD, Findugs or Junit complaining. But this is good. I'd rather deal with one issue at a time than with dozens like I used to before I used unit testing on my code. And I'd rather QA tools force me to keep the code looking good and doing things the right way, as I code, instead of having to go back and do cleanup for hours on end. I used to hate that, and would often cut corners or delay until it was too late.
The more I think about it, these tools and this process are analogues of the things we do in our lives to make managing them more efficient and positive. Get some work done every day, don't push off unpleasant things to the point they pile up into a huge chore, and monitor your progress, so you don't experience any nasty surprises. It's common sense, and it's about time, the same stress reducing techniques used in real life, become mainstream in software development.
No comments:
Post a Comment