beawolf - Fotolia
Refactor vs. rewrite: Deciding what to do with problem software
At some point, all developers must decide whether to refactor code or rewrite it. Base this choice on factors such as architectural soundness, time, money and goals.
When application source code becomes unmanageable due to patches, bad maintenance, freewheeling feature additions or other consequences of long operation, developers must either refactor or rewrite. In a refactor, developers make microchanges to clean up the code. With a rewrite, they throw almost everything away, and the coding process essentially starts anew.
Both of these options have advantages and disadvantages. Refactoring code helps keep it manageable without major overhauls but may not set the app up for new development technologies or application languages. Rewriting code enables foundational changes to the code but risks confusing developers or even breaking the product.
Don't think in absolutes for refactoring vs. rewriting code. Instead, determine which one is better for the particular project. This choice depends on factors such as the type of application, the team's capabilities, your long- and short-term goals for the application and your appetite for risk.
Let's examine the pros and cons of both refactoring and rewrites, and guidelines to make the right determination.
Refactoring code
When a programmer refactors software, the goal is to improve the internal structure of the code without altering its external behavior. For example, developers remove redundant code or break a particularly task-heavy application component into several objects, each with a single responsibility.
The extreme programming development approach, a concept known as merciless refactoring, stresses the need to continuously refactor code. Theoretically, programmers who refactor continuously make sections of code more attractive with every change.
Refactored code should be easily understood by other people, so developers can turn code that scares people into code that people can trust and feel comfortable updating on their own.
Advantages of refactoring
- Refactoring is always an option. The programmers who work on the code don't need anyone's permission to refactor it.
- You can refactor any software architecture type, from tightly monolithic to massively distributed.
- It can improve the quality of the code without slowing down progress. Programmers can refactor while they also move forward with deployment processes. Unlike a rewrite, refactoring does not require developers to maintain two separate codebases.
- If developers are only working on one part of the codebase, they can choose to clean up only the part they are working on. It does not add a great deal of cost to the project.
Disadvantages of refactoring
- While refactoring can improve a piece of code, it cannot fix underlying architecture problems. For instance, code written in Visual Basic 6 is still written in Visual Basic 6 at the end of the refactor.
- Because it maintains the status quo of architecture and code, refactoring does not open opportunities to add new functionality into an application.
- Refactoring requires skill, discipline and courage. Programmers who have never been exposed to the complexity of refactoring patterns may be unable or unwilling to dive in. Making these changes is scary without a unit test suite, and programmers unfamiliar with basic refactoring concepts may perceive that it slows them down.
- Because it breaks code into smaller chunks, refactoring creates a lot more code to manage and unit test. It changes complex functions into many simpler ones.
The discipline of refactoring is helpful when applications rely on thousands of lines of code. Refactoring breaks that up into abstracted, high-level objects, adds testability to those objects and keeps the functions reasonably small. However, when we start talking about hundreds of thousands of lines of code, it's time to move to the next level: a code rewrite.
Rewriting code
Rather than read and analyze complex, ugly code for refactoring, programmers can opt to just write new code altogether. Unlike refactoring, code rewrites sound relatively straightforward, since the programmers just start over and replace the functionality. However, it isn't nearly that simple.
To successfully rewrite software, developers should form two teams: one that maintains the old application and another that creates the new one. This means duplicating resources. Worse, the old system, still in production, needs updates and changes to keep it working. As such, the rewrite team must constantly reconfigure plans for the future product to match those changes in the existing one.
Advantages of rewrites
- Writing code from scratch opens the door for new users, markets, platforms and technologies. For example, rewriting is a way to move client-facing applications from a Windows desktop platform to a web-based, or mobile platform. Rewrites eliminate the headache of attempting to retrofit old code to meet demand for new technologies and application functions.
- A rewrite allows new developers to instantly implement code they are comfortable with. This advantage is especially attractive after a merger or acquisition. The rewrite creates a new, clean project -- a chance for developers to make their mark or complete a masterwork.
- Rewrites put the application on a platform that will make it easier to adapt to new development technology and approaches. Rewriting banishes legacy code, which decreases the gap between your existing software and emerging code options.
Disadvantages of rewrites
- Rewrites take time. You're essentially writing new software based on strict requirements. You should only commit to a rewrite if there is plenty of time to rebuild the application's code. As mentioned above, rewrites split resources between a team that manages the old code and a team that creates the new code. The maintenance team might not have sufficient experience with the old code to manage it appropriately.
- Old code is ugly and can get uglier. To rewrite the software, developers need to examine the old code, find the functions that should remain in the new product, and copy them. But another team is maintaining the old application code. In attempts to fix, update and clean the live code, programmers could potentially introduce defects. Those defects require bug fixes, and each bug fix makes the code a little bit uglier.
- Rewrites might not solve the problem of ugly code. Using an automated tool to port the application's code to another language is a viable option for rewrites and may save some time. However, these tools sometimes produce code that is exceptionally hard to read or maintain. The problem arises from an attempt to merge languages together.
