Slashdot Mirror
Study: Refactoring Doesn't Improve Code Quality
itwbennett writes: A team of researchers in Sri Lanka set out to test whether common refactoring techniques resulted in measurable improvements in software quality, both externally (e.g., Is the code more maintainable?) and internally (e.g., Number of lines of code). Here's the short version of their findings: Refactoring doesn't make code easier to analyze or change (PDF); it doesn't make code run faster; and it doesn't result in lower resource utilization. But it may make code more maintainable.
...is pretty important, and you should refactor when needed if only just for that. It'll spread all over rest of the code in many ways, in good ways.
the game
They employed inbred butt monkeys to refactor their code.
The "study" looked at a single, 4500-line program, with no way to properly define a baseline for any of the measurements. (Yes, they have "pre-refactoring" scores, but who's to say the initial version hadn't been refactored before? Maybe that refactoring was awesome.) This is not even close to news.
The compiler is what makes the final decision on the code, not the programmer.
Just refactoring a poor algorithm will still result in a poor performance, though the code might look better.
When you code, the most important thing to do is get your memory architecture built right, then methods just write themselves. Come back later and want to make a better method, you can use your old code as a partial refactor. It is an agile sort of run and gun approach and it works.
Refactoring for the sake of refactoring is often wasted time for the original author for there is ways of understanding code past just nice variable names and indentation. Sometimes even badly formatted code stands out and reminds you what it did to remind you of how it works. But when you code in a group, this doesn't hold true and a refactor can help.
God spoke to me
How any anyone say, or write, that refactoring doesn't make code easier to analyze or change, and then follow up with it can make it more maintainable? Also, who in the world ever though that refactoring would make code run faster?
We gave random medicines to groups of random people, and there was no statistical improvement in their health. Some people became healthier, but many people actually became ill.
Here's the short version of their findings: Refactoring doesn't make code easier to analyze or change
Contrasted with:
But it may make code more maintainable.
This makes no sense...
Isn't the very *definition* of making code more "maintainable" that it makes the code "easier to analyze or change"?
If the logic itself is convoluted, roundabout, or inefficient (ie n^2 sort onstead of n log n, exhaustive search instead of bisectioon search or kd-tree), prettying up the code won't help.
Firstly, I'm not sure what they think "more maintainable" means, if not "easier to analyze or change". Secondly, refactoring isn't supposed to make the code faster or less resource-intensive. So they're basically saying that it doesn't do what it's not supposed to do, and it both does and doesn't do what it is supposed to do.
Look at me, I'm so busy earning my pay! I'm a coder, bro!
Car repair does not make car faster, nor more comfortable.
Let's see... of the 5 main conclusions, 4 were statistically insignificant, and the 5th showed an improvement in maintainability. Thus the conclusion is don't do it. Sure, that makes sense.
But it may make code more maintainable.
Stating that something "may" do something, without additional qualifiers, is really no statement at all.
It must have been something you assimilated. . . .
The test case basically converted procedural/structural code (structs and test cases) to object oriented code (classes and polymorphism) for a small, 4,500 line project. What they basically added was extensibility at the expense of overhead and traded individual-line complexity with architectural complexity.
Isn't refactoring when you start doing the optimizations that were premature before, when you just wanted something that ran?
If my code looks scruffy then I refactor it. When I come back to it, I can read it better. That's all the empirical evidence I need.
Yeah. The conclusions are nonsense piled on more nonsense. Plus it is plain bullshit. Imagine I only refactor by removing duplicated code across functions or different compilation units. Will the compiled code size become smaller? Yep. Will be easier to read (less LOC to read)? Yep. Will it be more maintainable? Of course you have less code to bother with.
My thoughts exactly. More maintainable code IS higher quality code, in my opinion.
Making code run faster has a completely different name, it's called optimization (and is frequently the root of all evil). And it often involves the exact opposite of things you do when refactoring. Eg, unrolling a loop to make it run faster is pretty much the exact opposite of refactoring for maintenance & readability.
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
I hope not.
Required reading for internet skeptics
...don't be surprised if you end up with unmaintainable code..
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Isn't refactoring when you start doing the optimizations that were premature before, when you just wanted something that ran?
That's certainly one type. "Premature optimization is the root of all evil." - Knuth
No. Refactoring is when you take the awful, unmaintainable spaghetti code you produced when you were in a deadline crunch and convert it into something maintainable. The goal is to restructure the source code without changing the functionality at all.
There's no point in questioning authority if you aren't going to listen to the answers.
Sorry, but it has absolutely nothing to do with the real world. They're giving twenty people - ten in experiment group and ten in the control group 30 minutes to do a bit of analysis. And they measure minutes to apply a few changes, without any qualitative measure on how the code is growing. There's very little proof that the refactoring they did made any sense, the sample size is so low you'd never get reliable results and pretty much what you can conclude is that refactoring doesn't make hackjobs easier. Never thought so, that just involves finding the place something's happening and hack it. If it's a good idea, well... it works there and then.
Live today, because you never know what tomorrow brings
I wouldn't call that study publish worthy.
It certainly isn't statistically significant. 4,500 lines of C# code is nothing. I work with systems that have millions of lines of code. I've seen single class files that have thousands of lines of code (and vomited when I saw it). An important question here would be whether the volume of code in a system is a significant factor in the value of refactoring.
Based on their own statistics the refactoring was poorly done. Their result was more code, more complexity, and more coupling. Certainly not the work I would expect from an experienced software developer, but certainly something I would expect to see from undergraduate students who don't fully understand what they are doing.
I think the last sentence in the actual study sums it up pretty well - "Furthermore, it would be better that the same
experimental setup can be executed in industry environment with the industry experts and with
the industry level matured source code."
> The researchers selected a small-scale application (about 4,500 lines of C# code) used by the academic staff at the University of Kelaniya for scheduling events and managing online documents for evaluation.
My personal anecdotes have orders of magnitude more evidence than this study.
That's hilarious, I have web apps (I'm stuck with) having individual pages larger than that, including tons of other crap. Refactoring allows following the DRY principle and removing duplicated code. It allows moving SQL statements all the heck over the place into single places where they can easily be tested and updated when bugs are found.
They're basically working with a program that's not really that awful in the first place and making it a little bit nicer. How about starting with absolute junk and making it useable? Unmaintainable code is a consequence of technical debt, refactoring pays that debt down and keeps things manageable. Sure you may not need to refactor right now, but taking the time to do it once in a while keeps things from getting out of control.
Cwm, fjord-bank glyphs vext quiz
The study group size is 19 students. Does that bother anyone else? 19? Students?
There are so many problems with that study.
First, they use C#. There is no reason to think that it's not language independent.
Second, All the code was from one code base with 4500 lines! How can you extract anything statistically significant from basically 1 data point!
Third, supposedly 10 canonical re-factoring techniques were used. Could it be that these re-factoring techniques are useless? Of course, they are not discussed at all in the article. We don't know what re-factoring techniques they used (out of a big set from a different paper).
Fourth:
In order to apply 10 refactoring techniques a small scale project with bad smells was selected as
the source code. The selected application was a system which was implemented in the
Department of Industrial Management, University of Kelaniya and used by academic staff at the
department to schedule their personal and professional events and to manage their online
documents repository. The source code contained around 4500 lines of codes. The relevant bad
smells were identified and all the selected refactoring techniques were applied to the source code.
What?? They sniffed the code??? Makes absolutely no sense. I'd say the authors are idiots...
Oh yea, neither of the authors have background in CS. They're MIS (i.e. trained to be PHB).
The title is dying for "ON AVERAGE" on the end. The framing strongly suggests that it is a simple issue.
Like all pain, suffering is a signal that something isn't right
So I have a method that brute forces something, then I go back and figure out how to do it with a better big 0, and the functionality doesn't change, but that still isn't refactoring, because ... ?
I've seen the before-and-after when crap code was rewritten and refactored by hand by a good coder.
The improvement was huge.
Was it better than if the same coder wrote the code "from scratch" from the problem-description or design document? I don't know, but my point is that crap can be turned into gold by a good coder, and that refactoring can be part of the cleanup.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Nope, it's when I take the awful, unmaintainable spaghetti code someone else produced when they were in a deadline crunch and convert it into something maintainable.
Sigh... I wish I could say that with a straight face.
Interestingly, in my experience, poorly structured code seems to come about often less often because of "rushed code" but instead a lack of foresight in the original structure of a system to deal with continuously evolving features (which happens in most projects), along with a lack of willingness to refactor those systems as soon as it's apparent it's starting to break down.
This is the "golden time" to refactor code, because it's just now become apparent where the structural flaws are in the architecture, but it's still early enough to refactor without causing a significant amount of pain. It's often hard to justify, because you've only got a couple of ugly special cases that complicate things here and there. However, if you procrastinate too long, you're going to start piling on more and more "ugly special cases", and the code is going to get harder and harder to read and maintain.
Irony: Agile development has too much intertia to be abandoned now.
Refactoring is more than changing names.
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain
This paper is an introductary/exporitory look into the topic so I'll forgive the tiny sample sizes, but I'd really like to see appenicies showing the code before-and-after refactoring, and some discussion of the participants' skill level (besides mentioning in the conclusion that "expert developers would constitute a better evaluation"). I'll also point out that while C# is comparable to Java, refactoring one language is not the same as refactoring another; with C++ you have a lot more rope to hang yourself and the language is very much alive and kicking; for instance refactoring code to use smart pointers can prevent future bugs. You also have a lot more tools for refactoring the code such as lambdas and proper templates. C# is designed to be simple and is slow as a result, and I'd not be surprised if refactoring C# code does not improve either of these things a lot, although using proper data structures for the right job would be important. I don't mean to bash C# as I actually find some parts of it pretty nifty; I just want to point out that it's vastly different from C++ and that no study aiming to undertstand the impact of some good refactoring upon code maintainence metrics can focus on a single language.
Refactoring is the action of reviewing the code and re-writing it (internally only). Refactoring is in most cases done to increase readability and reusability (once again, internally only) which usually results in better maintainability. A by products of refactoring is detecting defects and optimization opportunities.
The paper does not mention who actually did the refactoring in the first place and how much was done, besides from:
"The relevant bad smells were identified and all the selected refactoring techniques were applied to the source code."
It then mentions showing the un-refactored source code to one group and the refactored to another group, then comparing results on a questionnaire.
So my conclusion could just as well be that this particular refactoring was done incorrectly
Comment removed based on user account deletion
Refactoring does not necessarily mean superior code.... it depends on the coder doing the coding and the refactoring as well as many other factors such as the history of the source itself.
Refactoring is something you should think of whenever you revisit your code to make changes as you are developing. Can I do this better? I don't know many programmers that write something once and it is perfect. Sure you can come back to it and make some changes that are necessary and do no thinking about anything other than just hacking in a change to make it work.... but that leads to worse and worse code, longer development cycles to deal with the repercussions of aging unmaintainable code etc. People have to start thinking of their source code as a depreciable asset not as an investment. A good percentage (depending on technology and industry the software is written for) of the cost of developing the system should be written off each year, and you require a certain amount of additional investment just in upkeep.
Of course to be able to properly refactor, your system cannot be a fragile system (lacks unit tests). If it is then refactoring may cause more problems than it solves. To properly refactor, you really need to have taken the time to write a full slate of unit tests as you were developing the system. This allows developers to be able to focus on the changes and be reasonable assured that if the tests say everything works, that the changes have not caused problems elsewhere in the system. If someone tries to measure refactoring as separate from all of the other good practices - you won't necessarily be able to measure much difference....
Making a judgment about "refactoring" as a single, simplistic concept is like making a judgment about "food" or "government" without going into any further detail. Umm, it's kind of not that simple.
Refactoring in real life is a whole array of different, nuanced activities. Any of them can be wise or foolish depending on the situation. Well-written code requires less of it, but some degree of it will always be needed as we can't tell the future. Each instance is a judgment call with no concrete right answer.
I would describe refactoring as increasing the level of abstraction involved in the code. This makes the code more robust and potentially reusable. However, a higher level of abstraction will take more time for a person new to the code to understand. I think this is why "more maintainable" and "easier to analyse and change" seem to be at odds with each other in the study, as students aren't going to have the ability to readily deal with the higher levels of abstractions as well as, say, more seasoned programmers. I don't count optimisation (dealing with specific bottlenecks) as refactoring (abstracting and generalising the code). They are totally different approaches.
In most times, most places, by most people, liars are considered contemptible. - Ursula Le Guin
The study was over a single application. From the article:
The researchers selected a small-scale application (about 4,500 lines of C# code) used by the academic staff at the University of Kelaniya for scheduling events and managing online documents for evaluation. 10 common refactoring techniques were applied to the code (e.g., Replace Type Code with Subclasses, Replace Conditional with Polymorphism).
Not only did they study just one application, but they limited refactoring to these 10 fancy techniques specific to object-oriented programming (from the research paper itself):
R1- Introduce Local Extension
R2- Duplicate Observed Data
R3- Replace Type Code with Subclasses
R4- Replace Type Code with State/Strategy
R5- Replace Conditional with Polymorphism
R6- Introduce Null Object
R7- Extract Subclass
R8- Extract Interface
R9- Form Template Method
R10- Push Down Method
In contrast, here are some things I do when refactoring:
- escape HTML in variables before embedding them in HTML, to seal against scripting attacks
- rewrite database queries to use parameters, instead of variables directly from user input, to seal against SQL injection
- move repeated code into functions
- Make app use just one database connection library instead of two. Yes, that's right, the app made two connections to the same database, through two different PHP libraries, on the same page. The only reason I can guess is that the last programmer meant to move from one library to the other, but left the company when he was right in the middle of doing so.
and a dozen other basic programming techniques. You had better believe that such refactoring improved code quality. Typically the code shrinks down to 30-70% its original size. Often it runs several times faster. For sure it is safer. And having merged code that was copy and pasted all over the palce, it is a lot easier to make changes to thereafter.
Theoretically, I shouldn't have to do these kinds of things, because a professional programmer should not strew such code behind them. But every single one of my fellow programmers or forebears here has committed these atrocities. For what it's worth, I work on a corporate intranet. So I probably see worse acts than at companies dedicated to software.
IT's the third world , if your coders are crap - of course you are going to have issues.
EOM
It can make code more "shareable". A tangled mess of globals can't be shared with anything.
It's hard to prove this with 4,500 SLOC.
... and removing duplicate code, turning some code into a reusable library that can be used in other projects, de-obfuscating "cute" code that you wrote in a midnight caffeine-fueled "in the zone" blur of clarity (you know this is not a contradiction if you've been there), calling an existing library that you found does the same job as your code but is more flexible, adding cross-platform #ifdefs, etc.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
who in the world ever though that refactoring would make code run faster?
Well if you were refactoring a brain dead method into something that had more smarts it is possible for the refactored code to run faster.
I am Slashdot. Are you Slashdot as well?
The #1 reason to refactor is to make code testable. The standard recipe is dependency injection with an IOC container, resulting in no live constructor calls, no dependency issues when a constructor changes, and decoupled dependencies. It's not a magic bullet but it's a big step in the right direction. Interestingly, testable code can have no tests and still be higher quality as a result.
from my blog on this, just now:
Proponents of refactoring have never ever said otherwise (unless they themselves are confused on the matter). Code is only readable if it is either simple, or clearly follows design patterns, or is clearly commented and the comments are up to date with the current version of the code. Code is only easy to change when it is readable and when all external dependencies are well known. That last part is a key thing that metrics aren't necessarily able to capture.
A refactoring project, if not refactoring to the right design patterns to address what was wrong with the structure in the first place, is not going to improve it. One must know clearly why the current structure is making a bug-fix or a new feature difficult to implement.
And while some refactorings are 'good' in that they reduce a lot of copy-paste code, others are good because they add code, or add classes (an alternative increase in complexity). Different refactorings have different effects, and are used in different situations.
And as always, if you don't need to refactor, don't. A refactoring is to improve the design, not to rewrite for its own sake.
And there-in lies the great flaw of the whole idea of such a study: you can't measure the quality of a software design. Some things you just have to judge for yourself, based on experience and attention, and no arbitrary metrics number will ever differentiate between a good design and a rubbish heap.
Disclaimer: I hate software metrics.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
So I have a method that brute forces something, then I go back and figure out how to do it with a better big 0, and the functionality doesn't change, but that still isn't refactoring, because ... ?
That is generally considered optimizing, not refactoring. By some definitions of refactoring I guess all optimizations are a form of refactoring, but that is almost never what someone means when they say refactoring.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
This is the whole problem with "narrow and deep" vs "wide and shallow." Too deep a hierarchy is just bad practice.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Most refactoring that I have observed over the last 30+ years was done primarily because the person handed the code did not understand it as it was. The refactoring process is very often the process through which a new developer figures out how old code works. Everyone likes to think that their refactoring was some sort of improvement over the previous code base, but the truth is this is only likely to be true about half the time. Considering that inexperienced engineers do more refactoring than experienced engineers, refactoring probably only brings actual improvement of any form to the code base less than half the time. The big plus is you now have a new guy that has ownership of something in the product. This benefit is hard to quantify, but should not be underestimated.
I don't buy the conclusion in the article at all, period.
1. When you refactor, you look over your source.
Programming is like any other kind of writing. The more you proofread, the more error-free your resulting work will be. While refactoring if all you're doing is copying and pasting code around, then sure, it does no good. But if you're paying attention to the code you're working with then you're also proofreading.
2. Improved interface = improved code.
The end functionality is not all that matters. Whether other programmers can use your code also has an impact upon how its quality will be perceived. When you refactor to improve an interface, you make your code more readable and more easily reused. That is most certainly an improvement.
3. Things change.
It wasn't that long ago that in C++, an insane number of malloc calls lurked behind every return. One could see this with callgrind, easily. Copies were copied and copied again just to get a return out of its function scope. Now we have move semantics. While you're refactoring, take a look and see if you can improve your performance with new language features.
4. Errors are not always obvious.
While refactoring, proofreading, and implementing new paradigms and patterns enabled by new language features, never stop compiling and running your code in your head. Sometimes ugly bugs don't show up until weird corner cases come around, but if you can think of that corner case ahead of time then you can nip it in the bud.
5. Get reacquainted.
While you're there, you might as well get to know your code well, once again. It has been a while since you've seen it, and hey, people forget. This is an excellent time to cozy up with a cup of coffee or hot cocoa and get to know the code you were once one with long ago.
If the conclusions drawn from a single case are generalized and promoted as gospel, be suspicious. Your competitors have a vested interest in teaching you to do things the wrong way. Should they ever succeed, may they be struck down by the fury of a thousand days maintaining the crap code they helped create by being underhanded.
A quote unfortunately used by a bunch of second rate coders to justify their lack of planning. I always get a chuckle when someone brings it out.
I once took over 30,000 lines of code that had been written by a subcontractor and trimmed it to around 4000 LOC. And you better believe it ran faster! Not because refactoring is magic, but because once all the mind-numbing almost-repetition was mucked out you could actually see what the code was doing and notice that a lot of it wasn't really necessary. Ever since then I have always maintained that coders should never ever copy and paste code. I've had people disagree, saying that a little bit of copying and pasting won't hurt, but I say if it's really such a little bit then you shouldn't mind re-typing it. Of course if you do that very soon you start putting more effort into devising ways to stop repeating yourself, which is exactly the point. Repeating yourself should be painful.
That's I think a reliable litmus test for whether you should refactor a piece of software. If it's an area of code that's been receiving a lot of maintenance, and you think you can reduce the size significantly (say by 1/3 or more) without loss of features or generality you should do it. If it's an area of code that's not taking up any maintenance time, or if you're adding speculative features nobody is asked for and the code will get larger or remain the same size, then you should leave it alone. It's almost common sense.
I don't see why anyone would think that refactoring for its own sake would necessarily improve anything. If an automotive engineer on a lark decided to redesign a transmission you wouldn't expect it to get magically better just because he fiddled with it. But if he had a specific and reasonable objective in the redesign that's a different situation. If you have a specific and sensible objective for reorganizing a piece of code, then it's reasonable to consider doing it.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Who? Quants?
That is, Quantitative Analysts. And it's kind of their job to say whether we, as coders, improve things by refactoring.
Should we bill the client those hours, or suck them up as something we were initially paid to do? Lots of arguments here, but there is a study that claims to have an answer.
How can anyone say?
Obviously, stats. How? Depends on stats.
You shut your mouth, How can you say I go about things the wrong way? I am human and I need to be loved Just like everybody else does.
r u a coder bro?
So I have a method that brute forces something, then I go back and figure out how to do it with a better big 0, and the functionality doesn't change, but that still isn't refactoring, because ... ?
Because it violates the standard definition of "refactoring".
Refactoring is about changing the structure of the code, and not the algorithms used within the code. The goal is typically to reduce coupling, increase cohesion, and (frequently) to improve testability.
Replacing an algorithm with a better algorithm isn't "refactoring", it's "rewriting".
Taking your giant brute-force method and breaking it into smaller parts in a cohesive unit (source file, class, package, etc.) with lowered coupling (perhaps by genericizing previously tightly-coupled bits), in such a way that the individual units have a smaller testing surface -- but is otherwise the same algorithm -- then you've refactored the code, by definition.
Yaz
Thanks for that irrelevant and very retarded comment.
I am completely in awe of your obvious level of experience and wisdom in this area...
Here's probably the best things I've seen written on refactoring: http://www.joelonsoftware.com/... & http://www.joelonsoftware.com/...
Are you fucking serious? That's pretty subjective. If you're talking about taking
string s = "";
s += "a";
s += "b";
to
string s = string.Format("{0}{1}", "a", "b");
Yeah, no difference. It looks prettier. How does that encompass all rafactoring. I've refactored sites and found major structural problems. Load times from 30 seconds down to 250 ms. Terrible use of recursion. Calling a method in a loop instead of once before the loop.
Like almost anything, YMMV.
This is the "golden time" to refactor code, because it's just now become apparent where the structural flaws are in the architecture, but it's still early enough to refactor without causing a significant amount of pain.
It can also be the golden time because the original writers are still around and know why certain things were done a certain way, and know what dependencies need to be addressed.
Interestingly, in my experience, poorly structured code seems to come about often less often because of "rushed code" but instead a lack of foresight in the original structure of a system to deal with continuously evolving features...
In my opinion poorly structured code too often comes from individual developers who just don't care. They show up to do a job and get paid; they got into CS because it was a way to make money; they don't really care about doing things elegantly. Or perhaps they care about quality but just don't understand the benefits of refactoring.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
I would describe refactoring as increasing the level of abstraction involved in the code.
I would say that refactoring can also be decreasing the level of abstraction. The goal isn't to create the highest level of abstraction, the goal is to create the right level of abstraction.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
There is a small wrinkle with the study: namely, that it makes *zero* sense to blindly apply refactorings. Each refactoring in the Martin Fowler book has an *exact* mirror refactoring, also found in the book. You have too many classes? He shows how to move away from it by using conditionals. You have too many conditionals? He shows how to use classes to get rid of 'em. If you apply each refactoring in his book, you will arrive at your original code!
Did the "study" authors fail basic reading comprehension, or are they being dull on purpose?
Ever since then I have always maintained that coders should never ever copy and paste code.
If you're just copying and pasting and leaving it unchanged then you're probably right. But I've certainly had cases where I needed to copy and paste a few lines of code maybe even 100 times and then tweak each instance to put in the data values or validations I want. Making a loop or making it somehow generic would have made the code unreadable and I would have had to put in a lot of extra code to handle a few special cases. That said, I'm only talking about a few lines of code beint repeated. If 15 or more lines are being copied then that does suggest a need for reusing the code.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
What about the case where all java classes are named the same (but in different packages)? I think refactoring would help quality.
nosig today
Doesn't it depend a lot on what you refactor, when and how?
I have 3 year old code that I would like to refactor because I've since switched framework (from CodeIgniter to Symfony 2) and it would bring it in line with all my other projects, allowing me more easy code-reuse and not maintaining two frameworks both on servers and in my mind. But it's largely a convenience factor and I would agree that it will probably not improve code quality very much.
But I also have 12+ year old code written in plain PHP with my own simple database abstraction layer. I'm quite certain that refactoring that would do a world of good.
Assorted stuff I do sometimes: Lemuria.org
Indeed. By introducing abstractions, you exchange performance and flexibility for simplicity (of one kind or another). More than one unmaintainable mess has been made by abstraction-hungry developers layering one leaky abstraction on top of another in a vein attempt to restore some of that flexibility.
This is why I'm a fan of top-down design. It tends to find the right balance almost automatically.
Required reading for internet skeptics
1. Take a small application that didn't need to be refactored.
2. Refactor it badly anyway.
3. Analyse the refactoring poorly with questionable metrics.
4. Conclude refactoring is rubbish.
If you want the opposite conclusion hire a new professor with a vested interest in proving refactoring works. Better yet make it a CIO at a commercial company. There will be all kinds of meetings about the new wonderful improvements and all sorts of wacky metrics to back that up.
Code runs. It continues to run. And, over time, the requirements change. Maintenance is adapting the code to the new requirements. If you don't understand why this is important, then I can only assume that no one is using code that you've written.
I am TheRaven on Soylent News
Sloppy Code works just as well as "Tuxedo Code" i.e. refactored code......
Why is this tagged Cod Equality? I mean, I'm all for fish rights, but that's just sil...heh.
it doesn't make code run faster; and it doesn't result in lower resource utilization. But it may make code more maintainable.
So, a research project that proved that refactoring does what it is supposed to do. What morons. That's the whole point. Maintainability. Take a piece of software that is going to have a 20 year life span written like hell and refactor it. Over the long term, the new devs that continually are tasked to work on it will have an easier time when actual OO techniques are used instead of the original spaghetti code.
Refactoring: Many small changes made without effecting functionality (that means no changes for performance improvements unless it is a mess and the result is a better performing unit of code) over the long term make a better product.
Maintainability, Readability, Object Oriented and all the other catch words associated with software development are all just lipstick on pigs. Software development isn't beautiful and you don't write software to win a beauty pageant. At the end of the day your software needs to be fast, stable, secure, expandable and dependable, anything that doesn't assist those goals needs to go.
What did this study think it was going to achieve? You can have the most readable and maintainable code in the world but if doesn't preform, then who cares. It's time to stop wasting time on catch phrases and return to the time when software development meant getting good code out.
A team of researchers in Sri Lanka set out to test whether common refactoring techniques resulted in measurable improvements in software quality, both externally (e.g., Is the code more maintainable?) and internally (e.g., Number of lines of code). Here's the short version of their findings: Refactoring doesn't make code easier to analyze or change (PDF); it doesn't make code run faster; and it doesn't result in lower resource utilization. But it may make code more maintainable.
From the OP, how the fuck do we reconcile this:
Refactoring doesn't make code easier to analyze or change
with this:
But it may make code more maintainable.
Seriously, those two statements conflict with one another. And since when refactoring was done primarily to make things run faster or more efficient resource-wise? Optimization is typically an architectural issue, or a point of local optimization in changing algorithms and data structures. Refactoring for the most part has always been about structural changes to enable analysis, re-usability and replacement and to ensure correctness (or at least to avoid introducing new fuck-ups.)
On The Onion News at 11, refactoring does not make code more eco-friendly/gmo-free.
There is so much wrong with the study, I can hardly decide where to begin...
1) They used a single project of 4500 lines of code. That's quite small. The project may have been fairly easy to analyze/debug/maintain even if the code quality is crap.
2) No objective measure was given of the "bad code smells" identified in the selected project.
3) It is possible they did a very bad job refactoring the code base. In addition to refactoring, they should have had other software professionals evaluate whether the "refactored" code was more maintainable in order to control for this.
4) There is no indication that they controlled for variability in the student's skill sets. The students who worked on the original code may have been much better students than those that worked on the refactored code.
5) The student group sizes were far too small to get meaningful results.
6) The "quiz" to determine analyzability consisted of 15 questions. This is far too small a size to determine how analyzable the code is.
7) The mean analyzability scores were 7 vs 6.63. This suggests the student's in both sets may have poor understanding of the code bases.
8) 10 refactoring techniques were not chosen based on applicability to the system in question, but were instead chosen based on previous studies that ranked the impact of refactoring on code quality. i.e. they treated refactoring as a "silver bullet" rather than deciding what types of refactoring were most applicable to the project in question.
There are so many flaws in the methodology that the results are meaningless. The only reason to waste time with this sort of nonsense is publicity.
Then you're doing it wrong.
Also how is improved maintainability not improved quality?
That's probably the number one reason I will refactor code - because someone who had more clever coding tricks than understanding of how other people read and parse code wrote some deep voodoo full of magic numbers that only they know what it all means.
But I've certainly had cases where I needed to copy and paste a few lines of code maybe even 100 times and then tweak each instance to put in the data values or validations I want.
This leads to bugs where a tweak gets missed in one of the copies (copy, paste, do tweak 1, interruption!, forget tweak 2). It also causes maintenance problems when the person coding a bug fix doesn't know there are a bunch of other places that need to be fixed.
"it doesn't make code run faster; and it doesn't result in lower resource utilization. But it may make code more maintainable."
I thought maintainability is the whole point of refactoring. If you want your code to run faster or use fewer resources, I'd say you need to optimize, not refactor.
any improvement done by the same group did not improve anything... coincidence? I think not
But I've certainly had cases where I needed to copy and paste a few lines of code maybe even 100 times and then tweak each instance to put in the data values or validations I want.
This leads to bugs where a tweak gets missed in one of the copies (copy, paste, do tweak 1, interruption!, forget tweak 2). It also causes maintenance problems when the person coding a bug fix doesn't know there are a bunch of other places that need to be fixed.
You're right that forgetting to do the tweak can be a problem. But as for not knowing there are a bunch of other places that need fixing, I guess I wasn't clear enough. The repetition gets centralized in a single file so that you can look over all the locations at once.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
"But it may make code more maintainable." -- in my experience this is usually the primary motivation for refactoring.