If you are working with Enterprise software, you will likely encounter legacy code. In face, most of the code you encounter may be legacy code.
What is legacy code? One acceptable answer is simply “Code with out tests”. Another answer is any code that is old, brittle, and riddled with difficult to manage dependencies. In general you’ll find that testable code fixes dependency problems and doesn’t feel old or brittle.
As a enterprise developer, you are bound to find a pile of legacy code that you need to change. When you hit this wall, you will need to define a strategy to fix this code over time. An article titled Technical debt 101 - “A primer about technical debt, legacy code, big rewrites and ancient wisdom for non technical managers”. This article pretty accurately describes the issues we face in estimating how long it will take to fix large chunks of bad code and running into problems so large the only answer is “the big re-write”.
The conclusion of the article is as such: The big re-write is incredibly expensive, is near impossible to estimate the amount of work to do, and loses functionality and therefore won’t work in many situations. The solution is slowly making things better over time.
One popular way of doing this Branch by Abstraction. What does this mean in this context? It means that you take a class A, create an interface A, and an “implementation” of that interface A call AImpl. Finally, you must connect all references of the original class A to AImpl via Dependency Injection such as Spring or Guice. All of that gets you exactly back to where you were ahead of time. So why do all of this work? Because the next step is to create a B “implementation” that doesn’t suck. Once BImpl is tested, flip the switch in Spring/Guice to use BImpl instead of AImpl.
This is not easy. But it is an actionable strategy for fighting legacy code without the big re-write. Once you’ve done the first class or service, moving on to the second class or service will be much easier.
We all love visuals, so here is a slide show describing the concept.
So there it is – don’t do the big re-write. Find something worth changing and do so one bite at a time.
This is how things are supposed to work.
Go to http://www.mixest.com/
Register yourself as a user on this site. Forget about the music selection or if you like the songs or not, that’s not what I’m getting at here.
You registered on this site, and the music never stopped playing. The pause button never even moved.
Intuitive, Concise, Effortless . This is how a UI should be made.