So what lessons can be learned from attempting to implement modern, safe, productive techniques into very old, monolithic, no-architecture software that has zero existing automated tests?
- It’s a lot harder than you think. Also, much more time consuming than possibly envisioned. And likely to not work.
- Example projects are simple and straightforward: as they should be. These all have the same baseline technologies. Legacy code has oodles of obsolete code/libraries & practices or techniques that hurt the logic part of your brain. The take-away is that this pain is a measure of the gap between good code and the target specimen.
- If the specimen doesn’t have a great architecture, unit testing will quickly expose this fault. And bring the unit test effort to a very quick halt. It’s not easy to retrofit an architecture into legacy code.
- Legacy projects may be Visual Studio projects that have been “upgraded” over the years. Compare the internal text/xml from one of these to a clean project. If you’re faced with building a unit test project with VS 20112 (1st MS VS release with CPP unit test framework) with VS 2008 projects, the comparison of the internals can be daunting. Consider scrapping the old project files and re-create new instead of upgrading; it will force you to think through your compiler & linker options. Maybe even understand them – nah, no time for that!
- Legacy code means many cooks have been in the kitchen. Each genius has their own contribution create the “best” string class ever seen. You get the opportunity reconcile this tower of string Babble. You’ve heard it here; be prepared.
So then, what are your chances of success? Better define success on a limited scale, such as implementing a single unit test that can be executed with each build. This success vs cost will be very helpful towards future efforts.