About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2003.Dec.24 Wed
I occasionally see advice to wrap 'legacy code' behind a facade or wrapper, putting new, tested, code "in front" of the wrapper, and leaving the old untested legacy code behind the wrapper. The recommendation is to "gradually" replace functionality behind the wrapper with new code.
I'm sure this comes from good intentions, but I see this kind of thing in legacy code itself -- layers and layers of code written by different people over the years, large portions of it being 'dead' code, and the one thing all these layers have in common is that their authors avoided changing any of the previous layers of code.
The Lava Flow antipattern describes this kind of layering -- good for building mountains and the Hawaiian Islands in real life, bad for building mountains of code in software.
It seems to me that "wrapping" should be a last resort, and continuing to engage in the legacy code, simplifying it, removing dead code and unnecessary layers, adding tests and refactoring, should be preferred.
I have to add some disagreements to the Lava Flow write-up that I linked to above. That author writes "There is only one sure-fire way to prevent the Lava Flow AntiPattern. That is by ensuring that sound architecture precedes production code development." There is more than one way to skin a cat. The other, less phasist way, is to apply Merciless Refactoring as you evolve the architecture as reflected in the production code, so that you have a good architecture at all times, even if it isn't the architecture you had planned to have three months ago, before you understood the domain as well as you do today.
Another point "As suspected dead code is eliminated bugs will be introduced. When this happens, resist the urge to immediately fix the symptoms..." I would say, "undo". Only remove dead code, not nearly dead code. Write unit tests and acceptance tests to detect bugs that may show up from a refactoring, and undo your last code change when the tests detect an undesired change.