BT

Debunking Common Refactoring Misconceptions

| by Jonathan Allen Follow 641 Followers on Jul 17, 2008. Estimated reading time: less than one minute |

In comparison to Java, an emphasis on continuous refactoring is still relatively new in .NET. Besides having few ardent proponents, many myths linger around what refactoring really is and how it applies to the development process in general. Danijel Arsenovski, author of Professional Refactoring in Visual Basic, attempts to dispel some of these myths.

After you read Danijel Arsenovski's "Debunking Common Refactoring Misconceptions", you may want to check these refactoring tools.

ReSharper As well as refactoring it also brings many other features from the popular Java IntelliJ IDE to the the C# world, so much so that many of my buddies already can't manage without it.

C# Refactory Fully integrated with Visual Studio - adds a very comforting "Refactoring" item to the edit menu.

Refactor! A general .NET refactoring tool that supports both C# Visual Basic and C++. There are free versions available for C++, ASP.NET and Visual Basic.

Visual Assist X Refactoring tool for Visual Studio handling all three .NET languages.

JustCode! Plug in for Visual Studio (2003 and 2005) offering refactoring and other code analysis and assist features.

For other languages and IDEs, see refactoring.com.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

"If It Ain't Broke, Don't Fix It" by Jim Leonardo

"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.

Small Methods & Performance - the view of one of the fathers of refactoring by Philip Schwarz

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.

Re: Small Methods & Performance - the view of one of the fathers of ref by Jim Leonardo

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.

The Elements of Style by Michael Hunger

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:



Michael, who loves Refactoring above all :)

Lets make a rule that we cannot waste our time via debating proven facts by Damon Wilder Carr

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

Like Programming, Refactoring is an art than science. It is very difficult. by Ashok Guduru

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

Re: Like Programming, Refactoring is an art than science. It is very diffic by Damon Wilder Carr

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

Re: Small Methods & Performance - the view of one of the fathers of ref by chris mo

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.

Re: Small Methods & Performance - the view of one of the fathers of ref by john mish

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

A pragmatic guidance for refactoring process by Mariusz Sieraczkiewicz

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss
BT