- Taking Responsibility
- Applying Feedback
- Pragmatic Environment
- Coding Techniques
- Sign Your Work
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Pragmatic Environment
The proper programming environment is the foundation of all pragmatic developments. If the foundation isn't solid, nothing built on top of it will be solid. But we want to create more than just a solid foundation; we want a safety net that allows us freedom to experiment while protecting us from the occasional "bad technology" day.
The first thing you need is a version control system such as CVS. You wouldn't think that this idea would be a hard sell, but if you look around at the teams developing software today, there are those that still don't use any sort of source code control. They'll use a shared disk that contains all of the source code, and the "last one in, wins." More commonly, you'll find teams that use a version control system, but not for everything. Some files are left out: documentation, build scripts, the CD-ROM burn list, and all those other odd little bits that are needed for the project, but aren't actually code.
Of course, the right thing to do is to put everything under source code control. We keep our address books, memos, and MP3 playlists under version control. Version control gives us the first part of our safety net: As long as you check in and out frequently (several times a day, for example), you can always go back to an earlier version of any file, even of one that has since been deleted.
Now we can go to stage two: automation. We like to have the code built completely, automatically, and unattended at least every night, or continuously if there's a spare box available. Besides assuring that the codebase still compiles, we also arrange to execute all the unit tests, with some sort of a summary report on a web page to tell us that the build and tests all ran okay.
And that's stage three of our safety net. With extensive unit tests in place that verify our assumptions about what the code does and doesn't do, and automation to ensure that all of our assumptions still hold, our safety net is complete. We're now free to try out experimental ideas and refactor acres of code with confidence that we haven't broken anything. If we do break something so badly that we can't see how to fix it, we can hit that big UNDO button in the sky and use the version control system to go back to the previous version.
We talk more about this subject in our column in January's IEEE Software magazine, available online.