BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Debunking Common Refactoring Misconceptions

Posted by Danijel Arsenovski on Jul 16, 2008 |

It is fair to say that in .Net community refactoring had a slow start. Even today, Visual Studio, a flagship product for development in .Net is hardly crossing the Refactoring Rubicon (http://www.martinfowler.com/articles/refactoringRubicon.html) with C#. With Visual Basic, or more recently with C++, a situation is better, but only if you download and install free refactoring add-in, Refactor! for VB or C++ developed by Developer Express.

After that, all alternatives are products you have to pay for. And while these products are certainly worth the investment, knowing the dynamics of corporate acquisitions when non-essential and esoteric arguments like "code quality" are concerned, they will have a hard time reaching anywhere near the developer mainstream. While you can refactor without a tool, manual process can be arduous and is definitely less attractive. No wonder than that .Net community is lagging behind in refactoring adoption and that there is still a lot of confusion regarding the whole issue of refactoring and its usefulness.

In this article, I have tried to list some of the misconceptions I come across the most often. These, together with some traditional programming preconceptions can often present an important hurdle in a process of adoption of this valuable technique. In continuation, I will list these preconceived obstacles, try to explain their origins and give good arguments in refuting them. I hope this will prove useful for anyone that still has a doubt on true nature of refactoring, to anyone learning to refactor or working on establishing and spreading this practice inside his team.

"If It Ain't Broke, Don't Fix It"

Often portrayed as longstanding engineering wisdom, "If It Ain't Broke, Don't Fix It" posture only promotes complacency. Refactoring teaches against it, and for a good reason.

Early on in your programming life you learn how even a minuscule detail in code can make huge difference, often paying dearly for this knowledge. A small change can provoke software to break in a surprising manner and at the worst of the moments. So once you have burned your hands you can often become reluctant to make any change that is not absolutely necessary. This can work well for a while. Inevitably however situation comes across where bugs have to be resolved and petitions for new features cannot be evaded anymore. You are faced with the same code you tried so hard not to confront.

Those who adopt "if it ain't broke, don't fix it" position look upon refactoring as unnecessary meddling with something that already serves its purpose. Actually, this conformist posture that tries to maintain the "status quo" is the result of intent to rationalize the fear of confronting the code and the fact that you do not have control over it.

Many experienced programmers adopt this posture because of legitimate intent to minimize any effort that is not really necessary. For example, if application is doing fine performance wise, then there is no need to squeeze that last processor cycle out for performance sake. Similar goes for speculative design, often argued with "We might need that feature one day" kind of prophetic programmer talk.

In that sense, refactoring is pretty much on the same wavelength. When you refactor, you should eliminate dead code, avoid speculative design or premature optimization.

However, for refactoring adepts, software can also be broken on the "inside". If the design is flawed, code poorly written and badly structured, then even if application is serving users correctly at the moment, and is not broken visibly on the "outside", it should still be refactored and design "fixed". In that sense, refactoring insists on some less tangible, but decisive characteristics of software like design, simplicity, improved source code comprehension, readability and alike.

Refactoring will help you win back the command over your code. While this is hardly an easy task with code base that has grown out of control, without refactoring the only solution you can look up to is the complete rewrite.

Refactoring Is Nothing New

This misconception could be restated as, "Refactoring is just another word for what we all know already." Which means you have all learned about good code, object-oriented design, style, good practices, and so on, and refactoring is just another buzzword that someone invented to sell some books.

Okay, refactoring does not pretend to be imposing radically new paradigms like object-oriented or aspect oriented programming when they appeared for the first time. What it does do is radically change the way you program: it defines rules that make it possible to apply complex transformations to code at the click of a button. You do not look at your code as some frozen construct that is not susceptible to change. Instead, you see yourself as capable of maintaining the code in optimum shape, responding efficiently to new challenges and changing the code without fear.

Refactoring Is Rocket Science

Programming is hard. It's a complex activity that requires a lot of intellectual effort. Some of the knowledge can be very difficult to grasp. With Visual Basic .NET, VB programmers had to acquire the ability to work in a fully capable object-oriented language. For many, this was baffling at first. The good part is that learning new skills definitely pays off.

The great thing about refactoring is how simple it can be. It equips you with a very small set of simple rules to start off. This, coupled with a good tool, makes first steps in refactoring a breeze. Compared to other techniques an advanced programmer should know nowadays, like UML or design patterns, I'd say refactoring has the easiest learning curve, a lot like VB itself compared to other programming languages.

Very soon, the time spent in learning refactoring will start to reap rewards. Of course, as with any other thing in life, gaining mastery requires a lot of time and effort.

Refactoring Causes Poor Performance

A longer way to state this might be, "Because after refactoring you usually end up with a larger number of more fine-grained elements like methods and classes, new design with so much indirection must incur some performance cost."

If you go back in time a little, you'll discover that this argument sounds curiously similar to the one used to voice initial skepticism toward object-oriented programming.

The truth is that the differences in performance between refactored and unstructured code are, at best, minimal. Except in some very specialized systems, this is not a real concern.

Experience shows that performance flows are generally afflicted by some precise spots in code. Fixing those during an optimization phase will get you the required levels of performance. Being able to easily identify the critical pieces of code can prove to be very valuable. By producing understandable code in which duplication and total size is minimized, where change can be performed in a single place, refactoring greatly aids process of optimization.

These days, when CPU horsepower is constantly incremented, some other aspects of code like maintainability, quality, scalability and reliability are forcing performance out of the top priority code features. Now, don't use this as a pretext to write code that performs lousy, just don't overdo it.

Just in case you would like to see some numbers here, I have prepared a small experiment. I will use two code samples; first is an example of poorly structured code and has single Main method. Second example has a Main method inside a Module and a class Circle with number of fine-grained methods. I have originally used these samples to illustrate unstructured vs. structured code style, so all it lacks is some measurement code.

I will measure the time it takes to execute simple geometrical formula (circle circumference length) and in order not to make out of this code calculation sensitive application, I will add some database query code. In order to even out the measurement, I will repeat execution inside a loop for 10000 times. Since I don't mean to make out of this extremely precise experiment, I will use System.Diagnostics.Stopwatch class to capture the interval; precision of Stopwatch will suffice in this case.

Code Sample 1: Unstructured Code

Option Explicit On
Option Strict On

Imports System.Diagnostics
Imports System.Data.SqlClient

Namespace RefactoringInVb.Chapter9

Structure Point
Public X As Double
Public Y As Double
End Structure

Module CircleCircumferenceLength

Sub Main()
Dim center As Point
Dim pointOnCircumference As Point
'read center coordinates
Console.WriteLine("Enter X coordinate" + _
"of circle center")
center.X = CDbl(Console.In.ReadLine())
Console.WriteLine("Enter X coordinate" + _
"of circle center")
center.Y = CDbl(Console.In.ReadLine())
'read some point on circumference coordinates
Console.WriteLine("Enter X coordinate" + _
"of some point on circumference")
pointOnCircumference.X = CDbl(Console.In.ReadLine())
Console.WriteLine("Enter X coordinate" + _
"of some point on circumference")
pointOnCircumference.Y = CDbl(Console.In.ReadLine())
'calculate and display the length of circumference
Console.WriteLine("The lenght of circle" + _
"circumference is:")
'calculate the length of circumference
Dim radius As Double
Dim lengthOfCircumference As Double
Dim i As Integer
'use stopWatch to measure transcurred time
Dim stopWatch As New Stopwatch()
stopWatch.Start()
'repeat calculation for more precise measurement
For i = 1 To 10000
'add some IO
Dim connection As IDbConnection = New SqlConnection( _
"Data Source=TESLATEAM;" + _
"Initial Catalog=RENTAWHEELS;" + _
"User ID=RENTAWHEELS_LOGIN;" + _
"Password=RENTAWHEELS_PASSWORD_123")
connection.Open()
Dim command As IDbCommand = New SqlCommand( _
"SELECT GETDATE()")
command.Connection = connection
Dim reader As IDataReader = command.ExecuteReader()
reader.Read()
reader.Close()
connection.Close()
radius = ((pointOnCircumference.X - center.X) ^ 2 + _
(pointOnCircumference.Y - center.Y) ^ 2) ^ (1 / 2)
lengthOfCircumference = 2 * 3.1415 * radius
Next
stopWatch.Stop()
Console.WriteLine(stopWatch.Elapsed)
Console.WriteLine(lengthOfCircumference)
Console.Read()
End Sub
End Module
End Namespace

Code Sample 2: Structured Code

Option Explicit On
Option Strict On

Imports System.Data.SqlClient

Namespace RefactoringInVb.Chapter11
Public Structure Point
Public X As Double
Public Y As Double
End Structure

Module CircleCircumferenceLength

Sub Main()
Dim circle As Circle = New Circle
circle.Center = InputPoint("circle center")
circle.PointOnCircumference = InputPoint( _
"point on circumference")
Console.WriteLine("The length of circle " + _
"circumference is:")
Dim circumference As Double
Dim i As Integer
'use stopWatch to measure transcurred time
Dim stopWatch As New Stopwatch()
stopWatch.Start()
'repeat calculation for more precise measurement
For i = 1 To 10000
circumference = circle.CalculateCircumferenceLength()
Next
stopWatch.Stop()
Console.WriteLine(stopWatch.Elapsed)
Console.WriteLine(circumference)
WaitForUserToClose()
End Sub

Public Function InputPoint(ByVal pointName As String) As Point
Dim point As Point
Console.WriteLine("Enter X coordinate " + _
"of " + pointName)
point.X = CDbl(Console.In.ReadLine())
Console.WriteLine("Enter Y coordinate " + _
"of " + pointName)
point.Y = CDbl(Console.In.ReadLine())
Return point
End Function

Private Sub WaitForUserToClose()
Console.Read()
End Sub
End Module
Public Class Circle
Private centerValue As Point
Private pointOnCircumferenceValue As Point
Public Property Center() As Point
Get
Return centerValue
End Get
Set(ByVal value As Point)
centerValue = value
End Set
End Property
Public Property PointOnCircumference() As Point
Get
Return pointOnCircumferenceValue
End Get
Set(ByVal value As Point)
pointOnCircumferenceValue = value
End Set
End Property

Public Function CalculateCircumferenceLength() As Double
QueryDatabase()
Return 2 * 3.1415 * CalculateRadius()
End Function

Private Function CalculateRadius() As Double
Return ((Me.PointOnCircumference.X - Me.Center.X) ^ 2 + _
(Me.PointOnCircumference.Y - Me.Center.Y) ^ 2) ^ (1 / 2)
End Function

Private Sub QueryDatabase()
Dim connection As IDbConnection = New SqlConnection( _
"Data Source=TESLATEAM;" + _
"Initial Catalog=RENTAWHEELS;" + _
"User ID=RENTAWHEELS_LOGIN;" + _
"Password=RENTAWHEELS_PASSWORD_123")
connection.Open()
Dim command As IDbCommand = New SqlCommand( _
"SELECT GETDATE()")
command.Connection = connection
Dim reader As IDataReader = command.ExecuteReader()
reader.Read()
reader.Close()
connection.Close()
End Sub
End Class
End Namespace

After few executions, you can see that times for both samples are pretty close. On my machine these values are in neighborhood of 2.2 to 2.4 seconds. One small difference I could appreciate is that the best time for unstructured sample was 1.9114800, while for structured it was 2.0398497. Not a huge difference in my opinion.

Refactoring Breaks Good Object-Oriented Design

Well-structured and refactored code can look awkward to an untrained eye. Methods are so short that they often seem without substance. Classes seem without enough weight, consisting of only a few members. It seems as if nothing ever happens in your code.

Having to manage a greater number of elements like classes and methods can imply that there is more complexity to deal with.

This argument is actually misleading. The truth is that the same complexity was always present. In refactored code however, it is expressed in much cleaner, more structured manner.

Refactoring Offers No Short-Term Benefits

There is overwhelming consensus between refactoring converts that refactoring actually makes you program faster. So far, I do not know of any study that I could call upon in order to prove what I just said, but my own experience tells me this is the case. It is only logical that this is so. Because you have a smaller quantity of code overall, less duplication, and a clearer picture, unless you are dealing with some trivial and unrealistically small scale code, refactoring benefits become apparent very soon.

Refactoring Works Only for Agile Teams

Because it's often mentioned as one of the pillar techniques in agile methodologies, refactoring is interpreted as working only for teams adhering to these principles.

Refactoring is indispensable for agile teams.

Even if your team has a different methodology, most of the time you are the one in charge of the way you code, and this is where refactoring comes along. Other team members or management might even be oblivious to the fact that from time to time you reach for "Refactor" option inside your IDE. So there is nothing to prevent you from refactoring your code no matter the methodology your team might subscribe to. Best results in refactoring are achieved if you adopt refactoring in small steps, performing it regularly while you code. Some practices, like strict code ownership or a waterfall process, can play against refactoring. If you can prove that refactoring makes sense from a programming point of view, you can start building your support base, first with your peers and then by spreading the word to the rest of your team.

Refactoring can be applied as a separate stage in development process and performed by separate team

This one is generally favored by managers. Being able to look at refactoring as a separate stage, and placing it somewhere between implementation and testing phase, can give a false sense of control from managerial point of view where tasks and resources are often viewed as bars on some Gantt chart that can be easily squeezed or moved around.

The truth is that in order to perform refactoring successfully, you should have full understanding of the problem domain, be aware of requirements, the design and even implementation details. If you do not form the part of the team from the beginning, you did not spent time in working with clients, analyzing requirements and thinking about the design, you will have hard time improving something constructed by the original team.

Following the model where code can be refined a posteriori akin to some substance in some industrial process will generally bring few benefits. Without good understanding of what the code is actually doing, refactoring you can really perform with confidence will bring only small improvements. If you try to make any substantial change in such circumstances, results will most probably be quite opposite of what is supposed to be achieved. Instead of making code relate better to problem domain, you will probably make things worse and end up introducing bugs into your application.

Refactoring can work just as well without unit tests

I imagine some simple refactorings can be performed even without unit testing in place. Refactoring tools and compiler itself can bring limited safety net that you can count on to catch some simple human mistakes. You can also test the code in traditional ways, using debugger or performing functional tests. These manual testing methods tend to be tedious and unreliable. And with refactoring, your code is more susceptible to change than ever. Avoid unnecessary problems, add some NUnit tests to your project and you will be able to test for errors with each small step you make.

Not relying on comments can't be right

Guaranteed to produce those funny looks of confusion and disbelief. I'm sure you have been told a number of times that you should write comments in your code. This is thought as a good programming practice that will help others understand your code. It is often interpreted as a sign of good, systematic and professional approach to coding. So if now someone dares to tell you that comments are not such a good idea, then that must produce certain amount of surprise.

The motivation for writing comments is often same as for refactoring your code. You should write code that is readable by humans. In early days, your tool often had a limit on identifier character length that could be used so the comments were the only choice for delivering some meaning to other human beings. The difference is that form refactoring standpoint, you should use code itself to carry the meaning, by choosing correct method, class, variable and other identifiers. Also, you should avoid using comments for that same purpose because comments do not get executed so they can easily get obsolete. In a hurry of typical day-to-day toil, it is so easy to change the code and miss to update the comments, documentation, diagrams and other secondary artifacts.

What's wrong with Hungarian notation?

It must be that those who coined the term Hungarian notation didn't have only Charles Simonyi's native tongue as inspiration. I wouldn't be surprised if names like a_crszkvc30LastNameCol and lpszFile sounded like Hungarian to them. These days, compiler will take care of type safety and will track type information. In modern IDEs, all necessary type information can be found at the tip of your mouse pointer. In languages like C# and VB.Net, Hungarian notation has outlived its usefulness.

Yet again, changing some old habits can be painstaking. Hungarian notation is often viewed as useful programming practice, one that is not implemented without some effort. No wonder then that not everyone will be happy to find that his traditional naming scheme is largely obsolete.

Using easily readable name that resemble natural, human language will greatly improved clarity of your code. Give up those funny prefixes and use words that other humans can easily understand.

Conclusion

While it would be probably too much to say that refactoring is revolutionalizing the programming, it is changing some old habits ground-up. This is bound to provoke some resistance and a decent amount of confusion among the uninitiated.

I hope you will find this article helpful as you embark on learning refactoring. You should not be taken aback with some issues that might put you off at first reading. And if you are promoting refactoring, or trying to educate others about it, then you should be ready to be questioned. In that case, I hope I have provided you with enough arguments that you might use to justify the true reasoning behind refactoring and necessity for its adoption.

This article has been adopted from the book "Professional Refactoring in Visual Basic" written by Danijel Arsenovski and published by Wrox.

About the Author

Danijel Arsenovski is an author of Professional Refactoring in Visual Basic published by Wrox. Currently, he works as Product and Solutions Architect at Excelsys S.A, designing Internet banking solutions for numerous clients in the region. He started experimenting with refactoring while overhauling a huge banking system, and he hasn't lost interest in refactoring ever since. He pioneered the use of refactoring as a vehicle for a VB 6 code upgrade to VB .NET. Arsenovski is a contributing author for different major publications, holds a Microsoft Certified Solution Developer (MCSD) certification, and was named Visual Basic MVP in 2005. You can reach him at danijel.arsenovski@empoweragile.com, and you can take a look at his blog at http://blog.vbrefactoring.com.

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

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

9 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT