Re-factoring and Antipatterns

[meenakshi sundar]

Hi Chris,

Do Re-engineering and Re-factoring are one and the same , How do they qualify to be Anti patterns?

Thanks

[Junilu Lacar]

meenakshi sundar wrote:
Do Re-engineering and Re-factoring are one and the same , How do they qualify to be Anti patterns?

Where/how did you get the impression that refactoring and/or re-engineering can qualify as an anti-pattern? And no, I don't see re-engineering to be the same as refactoring and I suspect that the book treats refactoring as something that you can do as part of a larger re-engineering effort.

[meenakshi sundar]

Appreciate your answer, I always had a believe that Re factoring is a subset of larger re engineering activity.Is that correct?

[Junilu Lacar]

meenakshi sundar wrote:Appreciate your answer, I always had a believe that Re factoring is a subset of larger re engineering activity.Is that correct?

"Refactoring", which is one word, no dash or space after "re", does not always have to be a part of a re-engineering effort. It is, in fact, its own thing that can be and should be done ruthlessly and relentlessly as you develop your application. Please follow the link I gave to more information about refactoring so you can understand exactly what it's about.

[Chris Birchall]

Hi guys,

Yes, I would say that refactoring is just one part of re-engineering a legacy project. Other important tasks often include: modernizing the software's surrounding infrastructure (for example using automation tools such as Chef or Puppet); improving the toolchain (e.g. the build tool, the version control system, the issue tracker, Continuous Integration); improving the visibility of code quality (using tools such as FindBugs); and most importantly improving communication within the development team, so that any new code you write doesn't instantly become legacy code.

As for anti-patterns, the biggest one I have seen is the "for the sake of it" pattern. By this I mean refactoring just for the sake of refactoring, or writing tests just for the sake of increasing test coverage by 1%. I think it's important to set clear goals to explain why you are refactoring, and what you want to achieve. If possible these goals should be linked to business value, even if indirectly. For example, if you are planning to add a new feature to a piece of legacy software, you could schedule one or two days beforehand, to do any refactoring that you think will make it easier to implement that particular feature.

Some more concrete examples of refactoring anti-patterns:

Refactoring for testability. This is fine at first, but once you have tests in place you should take another look at the new code. Does it make sense as a design, or is it only structured that way so you can write unit tests for it?

Inconsistent name-changing. Renaming a poorly named class or variable to something more understandable is a good idea in general, but if large parts of the codebase still use the old name for the same concept, you may actually make the code as a whole more confusing.

Refactoring too much at one time. As a rule of thumb, if it takes your colleague more than 5 minutes to review a change you have made, then your refactoring might be too big. You're more likely to make a mistake, and the reviewer is less likely to find it. Take it slowly, and refactor little and often.

[Junilu Lacar]

This makes a lot of sense. I have seen all of these and have even been guilty of some of them in the past. Another one, which I hesitate to classify as a refactoring anti-pattern, is changing code for the sake of "performance" based solely on gut feeling or intuition.

Changing code to improve performance may look like refactoring but it has a different goal: to change the way resources are used. That is, it's about efficiency. Refactoring is about changing the way code is organized to improve maintainability. (Full disclosure: paraphrased from Michael Feathers' WELC book)

[meenakshi sundar]

In practice, better factored code often runs faster and uses less memory as well. In this regard, optimization is closely related to refactoring having said that Premature Optimization is an AntiPattern.