Debunking Common Refactoring Misconceptions

"Ain't Broke" can mean different things. "Meets user requirements" is often what is meant, but I've seen plenty of code that "meets user requirements" but is actually broken in some way. Most often this means the code isn't meeting one of the "ilities" (usually maintainability or extensibility). If you have that 1000 line method that noone wants to touch, then even if it's meeting all the input/output requirements, it's broken. It's probably also got some bug lurking in there that simply hasn't been hit because the number of permutations needed to get there was more than anyone could test.

Excerpts from Kent Beck's Smalltalk Best Practice Patterns (1996):



Methods don't come for free. Managing all those bits and pieces of code - writing them in the first place, naming them, remembering, rediscovering, and communicating how they all fit together - all take time. If there is no benefit to be gained, bigger methods would be better than small because of the reduced management overhead.



Methods cost in performance as well. Each method invocation takes precious computer cycles. The trick to getting good performance is using methods as a lever to make your performance measurement and tuning more effective. In my experience, better factored code, with lots of small methods, both allows more accurate and concise performance measurement (because there aren't little snippets of code duplicated all over) and provides leverage for tuning (through techniques like Caching Instance Variable).



Overall, the goal of breaking your program into methods is to communicate your intent clearly with your reader, provide for future flexibility, and set yourself up for effective performance tuning where necessary.



...



Messages take time. The more small methods you create, the more messages you will execute. If all you were worried about was how fast your program would run, you would arrange all of your code in a single method. This radical approach to performance tuning invokes enormous human costs and ignores the realities of performance tuning well structured code, which often results in several order-of-magnitude improvements.



Simple minded performance tuning is not the only factor suggesting that large methods are best. Following the flow of control in programs with many small methods can be difficult. Novice Smalltalk programmers often complain that they can't figure out where any "real" work is getting done. As you gain experience, you will need to understand the flow of control through several objects less often. Well chosen message names let you correctly assume the maning of invoked code.



...



Small methods ease maintenance. They let you isolate assumptions. Code that has been written with the right small methods requires the change of only a few methods to correct or enhance its operation. This is true whether you are fixing bugs, adding features, or tuning performance.

I disagree that "small methods" mean less performance. IF the code is written correctly and tightly, then yes, there is extra overhead from making the extra calls, etc.


However, I think the benefits of writing small methods leads you into things that end up giving you better performance as a side effect. This is probably because you're getting better reuse, are avoiding rather than handling exceptions (which are very costly in many languages), and are just avoiding executing a bunch of "ifs". I agree 100% that it helps in performance tuning, not only in helping you isolate areas that may need it, but because you get better reuse, you can afford to spend more time in those areas that will give you the most bang for the buck.


All theories aside, I've generally found that large methods!=better performance, probably because the same people who write large methods probably aren't burning redundancy and inefficiency out of the system.

I find the values that Kent Beck proposes (most recently in "Implementation Patterns") of understandability, simplicity and flexibility (in that order) help very much in design. It is common sense now that you write software mainly for humans to read, understand, maintain and extend.


The power of current tools must not be underestimated. But the question is how well people can use their tools :)


I heartily suggest Resharper 4.0 for Visual Studio, it adds all the refactoring, navigation and highlighting features you are expecting from a modern IDE.


Regarding the section on "Refactoring Breaks Good Object-Oriented Design". Understanding the well structured design that comes out of refactoring is no problem when looking at it from top down.


But I had people having many problems when either coming from the bottom or looking for some specific thing that must be happening somewhere in this module. Being able to use the navigation facilities of your IDE certainly helps here.


Do you have other suggestions how to solve these two problems of making the "too structured" design more usable for your fellow developer? Are there any suggestions for code navigation / exploration tools?


I once thought about IDE-plugins that allow virtual inlines, i.e. produce a view of the code that inlines (up to a certain level) calls to other places and recreates the "big ugly method" which is for some people more easily readable and understandable.


Some more references:

• Refactoring: Martin Fowler


• refactoring.com


• refactoring.be


• Refactoring to Patterns: Josh Kerievsky


• Refactoring Software Architectures: Lippert & Co

Philip, compiler optimizations have made Kent's text you listed (critical in 1996) absolutely irrelevant with very minor exceptions. Both.NET and Java JIT/Optimize any relevance away there for your 'average bear'.

However as long as you KNOW this god, it's a critical part of what we do for fun. Anyway this post is not about Philip or anyone specific it's to 'everyone who codes for profit-seeking organizations'.

Dear Mr. Average Developer:

Let ORM replace your RSMBS knowledge. Just do it or it will be forced on you by the market. It's not value added knowledge it's destructive to knowing your domain.

One example of a much larger point. Apply the above to X where X = change your mind.

Code matters only as much as you can optimize the ability for your team to maintain it, reuse it and otherwise care post-release. All studies known by this brain which does live 1/2 in that academic but vastly underappreciated domain.

Your ability to simply meet what was asked is utterly irrelevant to others. You can only do bad.

Yet all anyone seems to care about is code. And who can blame them? In fact when there is not even an expectation to do anything else, who will change themselves to the new realities?

The superstars today write fluent APIs, DSLs, and code from the perspective of the consuming developers, the maintainers and ever the review of the business domain experts. Again success in meeting a need is not anything worth much then barely staying afloat.

But I have to remember most could care less about maximizing others and that is not for me to comment on.

The forces have made design the critical and lacking knowledge. Knowing C# is not important (knowing say high quality Linq Provider development in fundamental ways however is very important… Yet that’s the 20% or less).

There is nothing to be added that will mean anything on these subjects that is not rather minor and if so it will not happen by us.

Go re-read Eric Evan's book and for god sake fix those entities where you embedded all the DTO concerns and hard-coded dependences to NHIbernate and for god sake you can use your IoC/DI in far better ways by really designing injectable services and favoring aggregation, not specialization and for god sake those classes are no way Single Responsibility, and those subclasses your keeping are not able to pass the substitution test... There are many more areas more important.

Those needing to debate this leave behind to die. We must save ourselves.

Damon

Good article.

Refactoring is an art. It needs lot of passion and patience to do it. It is difficult to teach. Useually developers stop working once it starts working. They think that they've many things to do than refactoring this.

Thanks
Ashok Guduru

Refactoring is an art.

I have never heard it said quite like that. Why? There is rarely argument in fundamental ways on when a refactoring has improved the code without changing the context/behavior of the app.

Why do you see as art? I ask as my previous comment is trying to establish that we need to fix the misconceptions which were I though fixed.

"It needs lot of passion and patience to do it. "

No it requires a desire to be relevant. Are you saying that NOT refactoring is a valid alternative for developers? I can tell you to be even above average that is quantitatively wrong if your in a standard domain (80-90% of the needs where people pay developers to work).

"It is difficult t"o teach. "

Really? Only to people who refuse to scale their work beyond themselves. Anything is hard to learn if you refuse to see or accept the need, and/or you are vested in staying the same.

Here is one issue : Many developers feel refactoring is not 'fun'. They feel it is 'overhead'. Neither is true. It's far less fun to not be able to succeed because the code is utterly unmaintainable and you lack design.

Oh yeah. Refactoring a system which lacks any core design is like optimizing the endine in a car that doesn't start. You can always refactor but if refactoring is only done to benefit the person doing it, with no view to others benefit that is missing the point.

A person who fails to refactor cannot be on a 'above average' team by today's standard (which change quickly, far more so then previously I assert).

"Useually developers stop working once it starts working. They think that they've many things to do than refactoring this."

So what can offer in terms of a proposed solution? If offering a blanket statement so you allow this? Are you in a position to help change this? (note: you always have impact regardless of official title if on a team).

Again, I will state again, what justification does anyone have to argue that we should not refactor?

I thought so. So can we move on?

Damon

Response to the following false and misinformed claims:
False & misinformed claim #1
"there is no benefit to be gained, bigger methods would be better than small because of the reduced management overhead."
Benefits: increased readability & re-use + decreased maintenance time.
Reduced managment overhead? You need to read up on JIT compiler and method inlining.

False & misinformed claim #2
"Each method invocation takes precious computer cycles."
Performance is relative. "Precious computer cycles.". Dude, this is the 21 century not 1982. Do you exclusively program embedded devices or something? There are lots of far more significant ways to address performance such as through the use of caching. A few more (or even 1000 more) method calls in any real-world application is unlikely to make even a superficial difference.

I think the benefits of writing small methods leads you into things that end up giving you better performance as a side effect. This is probably because you're getting better reuse, are avoiding rather than handling exceptions which are very costly in many languages, and are just avoiding executing a bunch of "ifs".
Mish - club penguin

can be found in InfoQ article www.infoq.com/articles/refactoring-legacy-appli...