Rewrite or Refactor?
When you inherit code, how do you know when to spend time refactoring a particular class versus simply throwing that class out and rewriting it? How bad does a class, method, package, section of code have to be to warrant rewriting it?
On my current project, we have a few classes that are 1000s of lines of code in length with maybe one or two methods. These classes are very procedural and generally only have one unit test. (On the up side, they have about 80% code coverage) The powers that be have decided to scrap the current code and rewrite it. Under these circumstances, definitely agree with, and helped push, this decision. But this is a fairly extreme example.
Is this decision only faced in these extreme examples, or are there other legitimate reasons for rewriting code? In my experience, rewriting the code, if done properly (e.g., with refactoring and using TDD), would be faster and result in better results then refactoring.
The ramp up time on “reverse engineering” legacy code can be substantial. If you have clear requirements a rewrite may not be a bad idea.
What I usually see in practice though is that the requirements are *not* 100% and the legacy code contains various little bits of logic to handle accumulated undocumented reqs. Or it contains “features” that other logic depends on without necessarily realizing it.
When you have that rat nest of issues a rewrite usually ends up working until it gets to the end user or someone notices the new code does not handle case xyz properly or like the “old code did.”
If you have the time (who does?) you can begin covering the legacy code in behavior tests to discover just what it is doing. You can then apply those tests to your new code and ensure both sides pass.
Code coverage tools are essential to make sure you cover the old stuff sufficiently. Of course, by the time you get to this point, the pendulum swings back to just refactoring (since you now have an extremely high test coverage!)
No good answer yet. I usually lean towards rewrite because if it breaks a “feature” that isn’t spec’d out… it usually points to a bigger problem anyway.
Would you describe more about you experience??
By the way, the most difficult part of rewrite is to collect back the requirement, how do you overcome that?
I haven’t yet figured out a great way to collect “real” requirements yet. I’m not sure anyone has really (that I have seen).
Often it is because the stakeholders themselves do not know what they don’t know and don’t always know what they want. And sometimes they get what they want but it’s not what they need, etc. etc.
No silver bullets here.
@Carfield – We are going through that process right now. Thankfully we have a lot of documents in which those requirements were captured the first time; however, as Chris stated, those requirements are not necessarily right and going back over them gives the business a chance to take a second look at them.
So far, we are getting confusion over why we are doing the rewrite, but once we explain, the client is very willing to work with us to collect the requirements.
I _always_ favour refactoring, rather than replacing or creating parallel implementations. This is because I tend to look at software development from a systems perspective.
Instead of trying to understand all the requirements for a system as a whole, I prefer to try and understand _what the system currently does_ and _how I want to change that behaviour_. Changing behaviour could mean fixing bugs or adding new features. This applies equally at all levels of abstraction (eg. the entire business system, or a single interface/class).