What are the limitations of refactoring?

Question

I'm making a study on refactoring limitations on improving existing software architecture and I would be interested to hear your experiences where you have found refactoring to be not enough or still too immature to accomplish your goals.

Answer 1

Refactoring code that doesn't have a corresponding set suite of unit test can be risky. If the project already has an established unit test suite then provided that you maintain a TDD approach there should be little reason for concern.

Answer 2

Refactoring can be risky

Refactoring is often difficult because the refactorer often isn't the same person as the original designer. Therefore, he or she doesn't have the same background in the system and the decisions that went behind the original design. You always run the risk that bugs avoided in the original design may creep up in the new design.

This may be especially true when a new or young team member, not fully experienced with this system, decides to inject new-cool-wizbang technology or ideas into an otherwise stable system. Often when the new team members are not integrated well into the team and are not given sufficient guidance, they may begin forcing the project in directions unintended by the whole team.

This is just a risk, however, there's also a chance that the team is wrong and the new team member, if put in charge and was allowed to do his or her thing, would actually make a serious improvement.

These problems often come up amongst a team working on legacy systems. Often there are no world-altering enhancements planned, so the team is conservative with their design. Their goal is to prevent new bugs from being injected and fix old ones with a couple extra features thrown in. A new team member might come along and upset the apple cart by insisting that, he rewrite certain subsystems of the code. New bugs are created and users of a fairly stable product are upset because the software, from there perspective is getting worst.

So if your goal is long-term stability without major functionality changes, often major refactoring is not what you want.

If you have larger functionality changes in the pike however, have a user-base that expects your product to not be fully baked quite yet (ie you're in some sort of beta), then its a much better situation to consider serious refactoring because the long-term benefits of the superior design will pay off and you're less likely to disrupt a large user base.

Answer 3

I am not quite sure your question is valid. You're asking about the limitations of refactoring. However, refactoring involves the rewriting of code. How can there be limits to what you rewrite? You can completely replace the old code over the course of a massive refactoring, piece by piece. Effectively, you can end the refactoring without a single character of the original code, although this is admittedly extreme. Given this far end of the possibilities of refactoring, how can you assume there can be any limitations? If all the final code could possibly be completely new, you have no more limitations than if you had written the final code from scratch. However, writing the same resulting code from scratch gives you less basis to go on, less opportunity to iterative development, and so I must respond with a counter-question: Doesn't any refactoring inherently have less limitation than any rewrite?

Answer 4

Not all managers like the idea of refactoring. In their eyes, the time taken to refactor is not used to add new functionality. So you need either convince your manager that it is needed or you can hide it while adding features.

So the risk is to take too much time to refactor.

Answer 5

One problem with refactoring arises when you cannot change the outer interface of your classes. In these cases, you are very, very limited as to what you can refactor.

Answer 6

To Kev's excellent Answer - "Working Effectively with Legacy Code" by Michael Feathers should be required reading for people working in Software Engineering.