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.
The biggest problem with the study is it seems to miss the whole point of refactoring code http://en.wikipedia.org/wiki/C.... It is not about one project, it is all about a coding company and the code it produces over the life time of it's existence, about all of it's projects, past present and future. Is refactoring a technical waste for one project, depends upon the qualities of the initial code produced. Is refactoring a waste over 100 different projects over ten years, of course not and often because far less refactoring effort will be required for latter projects than earlier projects and those latter projects will be far more efficient.
It is much like the principles of TQM http://en.wikipedia.org/wiki/T.... Does Total Quality management work for one project, rarely the administrative costs will readily out weigh the benefits because there is little or no opportunity to apply the improvements provided by TQM. Will TQM provide benefits for hundred projects over ten years, of course because. As there is plenty of opportunity to apply the benefits gained from the administrative efforts expended on TQM.
Chaos - everything, everywhere, everywhen
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.
10,000 line functions are shockingly common in industry. Shit grows over time, and is so poorly written that you can't safely refactor it, and management lacks the balls to let you clean it up, so it just festers and festers.
I hear PayPal had 90% of their processing business logic in a single, multi-million-line class! Thankfully, I don't know that one first hand.
Socialism: a lie told by totalitarians and believed by fools.
About 5600 lines. However, because it was a glorified case statement, you were really only debugging a single case at a time, each of which was about the length of a sane function, so splitting it into functions would do little to improve readability. I like to trot out that example to terrify people, but the function itself was really quite sane and easy to maintain.
You did, however, have to fully understand the state machine as a whole, which in total was almost twenty kloc, had almost 200 instance variables in the state object, and leaned heavily on a tree object with about 30 instance variables. That's the point at which most people's heads exploded.
Either way, 4,500 lines is the size of a fairly straightforward iOS app. Most folks can dig into that and figure out enough to maintain it without spending a huge amount of time, even if the organization isn't ideal. When you hit tens of thousands of lines, that's where you have to start thinking about how you organize it and document it, because with such large projects, if you jump into the middle without a complete picture, you're likely to be hopelessly lost.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Yes, after 25yrs in the industry I have come to the conclusion that "what is it supposed to do?" is invariably the most difficult question to answer.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Of course part of the reason is that I refactor as I write.
I'm not sure what that has to do with writing "badly formatted code", but I'd still caution against that. Some of the best advice I ever received: "There are no good writers, only good rewriters." I've found this to be true for code as well. It's amazing how much you can improve your code once you've distanced yourself from it a bit.
Required reading for internet skeptics
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