Refactoring 101
-
A (long) interview with Martin Fowler here: http://www.artima.com/intv/[^]. Nothing terribly new if you're into this stuff (like me :-)) but an interesting read nevertheless. I went to a seminar on refactoring a few months ago and asked the guy a question that he wasn't really able to answer. Maybe somebody here can shed some light... Q: There are a lot of parallels between software engineering and architecture or engineering. Are there any (formal) processes in those disciplines akin to refactoring?
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
Are there any (formal) processes in those disciplines akin to refactoring? But as to your question--I would say yes. In California, and unfortunately now showing up in many other parts of the country, you can see these housing track developments where every house is the same, except that its mirrored in one or two directions. Then, a couple years go by, and another tract comes up looking very similar, but with subtle changes. A lot of these tracts are designed by the same architectural companies (there are only a couple megalithic players in the southern CA market). I strongly suspect, that with CAD systems, there is a considerable amount of refactoring. Building codes change and better building materials are found (or bad ones, such as PVC joints) and it would be silly not to re-use an existing architectural drawing as much as possible, or an engineering solution (say, plumbing or HVAC) to cut costs. And cost reduction is, unfortunately, the motivation for those housing tracts. Not just engineering/architectural design, but materials purchases, tooling, etc. They are so ugly. Also, having been inside several of these houses in the same tract, I am often surprised how the floor plans are vastly different, but the exteriors are the same. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
-
peterchen wrote: competent == experienced, right? Not necessarily. Competence implies experience. But I've worked at places where they keep making the same mistakes over and over again i.e. they have the experience but aren't smart enough to do anything about it. peterchen wrote: Sounds simplistic to everybody who's been through it. Again, not necessarily. How many times have you looked at a piece of code and thought "this is total crap! it's unfixable! we've got to throw it away and start again". fixing it bit my bit is, IMO, not the natural response in such a situation. What Fowler is saying that refactoring is perhaps the better solution and talks about techniques that can be used to help the process e.g. automated regression testing. And yes, Mozilla was a disaster! :-)
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
just to clear up: I was refering to Marc's use of "competent", and "been through it" meant: tried to rewrite some code for the better, and recognized it took twice as long as planned, and still lacks the goodies of the old code.
skulls don't kiss a machito [sighist]
-
A (long) interview with Martin Fowler here: http://www.artima.com/intv/[^]. Nothing terribly new if you're into this stuff (like me :-)) but an interesting read nevertheless. I went to a seminar on refactoring a few months ago and asked the guy a question that he wasn't really able to answer. Maybe somebody here can shed some light... Q: There are a lot of parallels between software engineering and architecture or engineering. Are there any (formal) processes in those disciplines akin to refactoring?
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
Taka Muraoka wrote: Q: There are a lot of parallels between software engineering and architecture or engineering. Are there any (formal) processes in those disciplines akin to refactoring? It's called remodeling or This Old House. (Of course these aren't "formal" but neither is refactoring, which is just a fancy word egghead types use instead of rewrite since they think it means something more. Engineers use it to make the rewrite more palitable to management [this isn't being sarcastic.])
-
Taka Muraoka wrote: Q: There are a lot of parallels between software engineering and architecture or engineering. Are there any (formal) processes in those disciplines akin to refactoring? It's called remodeling or This Old House. (Of course these aren't "formal" but neither is refactoring, which is just a fancy word egghead types use instead of rewrite since they think it means something more. Engineers use it to make the rewrite more palitable to management [this isn't being sarcastic.])
Joe Woodbury wrote: Of course these aren't "formal" but neither is refactoring, which is just a fancy word egghead types use instead of rewrite since they think it means something more. Refactoring is different from rewriting. Rewriting includes deleting the file and starting over. Refactoring takes existing code and changes the structure of the code without changing what it does. For example, eliminating duplication is a common refactoring, but it isn't rewriting. Cheers The universe is driven by the complex interaction between three ingredients: matter, energy, and enlightened self-interest.
-
Joe Woodbury wrote: Of course these aren't "formal" but neither is refactoring, which is just a fancy word egghead types use instead of rewrite since they think it means something more. Refactoring is different from rewriting. Rewriting includes deleting the file and starting over. Refactoring takes existing code and changes the structure of the code without changing what it does. For example, eliminating duplication is a common refactoring, but it isn't rewriting. Cheers The universe is driven by the complex interaction between three ingredients: matter, energy, and enlightened self-interest.
Mr Morden wrote: Refactoring is different from rewriting. Rewriting includes deleting the file and starting over. Since when? I rarely do rewrites like this nor has any engineer I know (though at times, it is necessary). I stand by my original statement that refactoring in practice is obfuscation of rewrite. Since nobody, including the people who bandy the word around like they've invented something new, knows what refactoring even means, it ends up meaning whatever each person thinks it means, which may be great politically, but wastes time in solving actual problems. Incidentally, elmininating duplication is best called "eliminating duplication", why invent a new word to confuse the issue?
-
Mr Morden wrote: Refactoring is different from rewriting. Rewriting includes deleting the file and starting over. Since when? I rarely do rewrites like this nor has any engineer I know (though at times, it is necessary). I stand by my original statement that refactoring in practice is obfuscation of rewrite. Since nobody, including the people who bandy the word around like they've invented something new, knows what refactoring even means, it ends up meaning whatever each person thinks it means, which may be great politically, but wastes time in solving actual problems. Incidentally, elmininating duplication is best called "eliminating duplication", why invent a new word to confuse the issue?
Joe Woodbury wrote: Since when? I rarely do rewrites like this nor has any engineer I know (though at times, it is necessary). I said includes. I didnt say that each rewrite involved deleting the file and starting over. Rewrite is a broader term than refactor, thus refactoring is more accurate for describing what is being done. Joe Woodbury wrote: I stand by my original statement that refactoring in practice is obfuscation of rewrite. It's more a specialisation than an obfuscation. Joe Woodbury wrote: Since nobody, including the people who bandy the word around like they've invented something new, And that's exactly who bandies the word around like they've invented something new... Nobody. Joe Woodbury wrote: knows what refactoring even means, it ends up meaning whatever each person thinks it means, Rubbish. Refactoring, according to the definition, means to improve the design of existing code without changing what it does. Simple as that. It's not very complicated. Joe Woodbury wrote: Incidentally, elmininating duplication is best called "eliminating duplication", why invent a new word to confuse the issue? Since eliminating duplication is just one part of refactoring. It encapsulates a lot more activities. Here are a few more, it's not an exhaustive list btw. Change bidirectional to unidirectional. Consolidate conditional expression. Extract Method. Extract Class. Replace constructor with factory method. Replace type code with state/strategy. The concept of refactoring has been around for a lot of years. It's a similar concept to the Design Patterns movement. The Refactoring movement (if you can call it that) has encapsulated a number of well known (and not so well known) refactoring patterns under a single banner. I don't understand the resistance. Cheers The universe is driven by the complex interaction between three ingredients: matter, energy, and enlightened self-interest.
-
A (long) interview with Martin Fowler here: http://www.artima.com/intv/[^]. Nothing terribly new if you're into this stuff (like me :-)) but an interesting read nevertheless. I went to a seminar on refactoring a few months ago and asked the guy a question that he wasn't really able to answer. Maybe somebody here can shed some light... Q: There are a lot of parallels between software engineering and architecture or engineering. Are there any (formal) processes in those disciplines akin to refactoring?
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
That was an excellent link - thank you, Taka. But who coined the term 'Refactoring'? What does it really mean? Periodic review and revision of code should be part of a normal business cycle. No solution delivered on the due date is ever as good as the designers would like it to be, and a happy customer is likely to come back someday. Doesn't it make good sense to revise and improve along the way so that when the customer comes back you already have in place a better solution? Great article - thanks again - but why do we need a new term for a good business practice? It seems like unnecessary obfuscation to me... "My child was Inmate of the Month at Mohave County Jail" - Bumper Sticker in Bullhead City, AZ
-
That was an excellent link - thank you, Taka. But who coined the term 'Refactoring'? What does it really mean? Periodic review and revision of code should be part of a normal business cycle. No solution delivered on the due date is ever as good as the designers would like it to be, and a happy customer is likely to come back someday. Doesn't it make good sense to revise and improve along the way so that when the customer comes back you already have in place a better solution? Great article - thanks again - but why do we need a new term for a good business practice? It seems like unnecessary obfuscation to me... "My child was Inmate of the Month at Mohave County Jail" - Bumper Sticker in Bullhead City, AZ
Roger Wright wrote: But who coined the term 'Refactoring'? Unsure, but I think its a fiancial term used for "factor" trading. Roger Wright wrote: What does it really mean? The way I learned it, was that code was made up of a quanity of factors to make the Product, So refactoring is reorganizing the factors so that the same Product is kept. I think it might actually have been coined by MF. Roger Wright wrote: but why do we need a new term for a good business practice? It seems like unnecessary obfuscation to me... Agreed, but their are $$$ behind having trendy words owned. Good for marketing etc. :-) Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
That was an excellent link - thank you, Taka. But who coined the term 'Refactoring'? What does it really mean? Periodic review and revision of code should be part of a normal business cycle. No solution delivered on the due date is ever as good as the designers would like it to be, and a happy customer is likely to come back someday. Doesn't it make good sense to revise and improve along the way so that when the customer comes back you already have in place a better solution? Great article - thanks again - but why do we need a new term for a good business practice? It seems like unnecessary obfuscation to me... "My child was Inmate of the Month at Mohave County Jail" - Bumper Sticker in Bullhead City, AZ
Roger Wright wrote: But who coined the term 'Refactoring'? AFAIK, it was Martin Fowler, the guy being interviewed, who conined the phrase. It came out with the whole Extreme Programming thing - now there's a buzzword for ya! We could have this whole discussion all over again about the merits of XP. I'd be on the other side of the fence this time, though :-) Roger Wright wrote: Periodic review and revision of code should be part of a normal business cycle. Yes, it should but I think refactoring is a little more involved than the simple "fix bugs and retest" concept that other people have mentioned. The cornerstone of refactoring, IMO, is the use of automated regression tests. These allow you to make changes to the code safe in the knowledge that you haven't broken anything. Or minimize the chances of doing so, at least. I've recently written a little scripting engine and have written hundreds of little test cases for it. Along the way, I made some fairly major architectural changes but my regression tests allowed me to do this without invalidating all the testing I had done to date. Running the regression tests let me know that everything was still OK and I was able to get the job done much more quickly and to a higher standard of quality than had I not have had these tests. Roger Wright wrote: Doesn't it make good sense to revise and improve along the way so that when the customer comes back you already have in place a better solution? The fundamental problem here, I think, is that it is well nigh impossible to prove a link between doing things like refactoring and end results like customer satisfaction. Or even the bottom line. Refactoring is particularly problematic because as far as the customer is concerned, nothing's changed. The functionality remains the same and s/he doesn't really care if things are radically different under the hood. OK, maybe the software will be more stable and less buggy but I think that Microsoft has proved to us all that this is not a pre-requisite for commercial success! And so, even if there is a measurable improvement at the end of the day, how do you attribute it to the refactoring you did? Your less-than-stellar managers are more likely as not to simply claim that it was a result of their superior management skills - I've seen it happen! And as far as coining a new word goes, I think it's a good idea as long as everyone understands that it means "fixing code + au
-
competent == experienced, right? Refactoring bears an important lesson: rather than throwing crap code away, and starting over, try to clean it up, fix a few bugs, clean up some more, add some feature. Rinse, repeat. In small steps, that always keep you a working product. Sounds simplistic to everybody who's been through it. However, how many newbies know about that? How many companies that wanted to "rewrite for the better" have been left behind by their competition, two years late, 200% over budget, with a product that's almost the market leader - of last decade. Look at the Mozilla desaster. If they would have refactored what they had, instead of writing a a new renderer, a new UI language, a new bug tracking system, and new whatnots, my server logs wouldn't show up Mozilla with <3%. Refactoring is a lesson we have to teach newbies. But I agree: This Fowler guy is so much "buymybook", he should be banned from that job.
skulls don't kiss a machito [sighist]
peterchen wrote: Refactoring bears an important lesson: rather than throwing crap code away, and starting over, try to clean it up, fix a few bugs, clean up some more, add some feature. Rinse, repeat. In small steps, that always keep you a working product. That's so true. At the moment our product (Pharos - an acoustic tracking system) is currently evolving from a monolithic app to a componentised one, as a result of which a significant proportion of the code is being reworked. It's obvious to me that when you do this interfaces change, which causes major risk. The ability to support old interfaces and behaviour for a while (say 3 months) after the switchover reduces that risk significantly. This is even more important when there's a product release in the not too distant future. A little while ago this lesson was reinforced here when a co-worker (in our case an ex-team leader on another site!) hadn't learnt the same lesson and broke major functionality with an interface change without realising - or telling anyone. It wasn't particularly pleasant. Anna :rose: "Be yourself - not what others think you should be"
- Marcia Graesch -
A (long) interview with Martin Fowler here: http://www.artima.com/intv/[^]. Nothing terribly new if you're into this stuff (like me :-)) but an interesting read nevertheless. I went to a seminar on refactoring a few months ago and asked the guy a question that he wasn't really able to answer. Maybe somebody here can shed some light... Q: There are a lot of parallels between software engineering and architecture or engineering. Are there any (formal) processes in those disciplines akin to refactoring?
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
Taka Muraoka wrote: refactoring Got to love coincidences. Was just reading a "behind the scenes" article on Gamespot about Maxis (guys who made SimCity, The Sims etc.) The coincidence bit was this:"The bottleneck wasn't in the design. The problem was the engineering and the architecture. "The code was like a big bowl of spaghetti that was all tangled up," Barthelet explains. "I looked at the way this game was going and said, 'Listen, we have to stop this right away. We have to cut all the code apart and figure out how to connect all the parts of the game again.'" While everyone on the team realized that the core game technology wasn't stable, Barthelet's insistence on completely reengineering the game's infrastructure was a devastating decision. "It was a difficult decision to make," he admits. "I had to look people in the eyes and say, 'Listen, we're going to stop development and begin a process called refactoring.'" A programmer is perplexed by some of the 3 million lines of code in the game. Refactoring, a programming term, refers to the process of pulling the game's underlying architecture apart and figuring out the most efficient way to reconnect each individual part. For a programming project with 3 million lines of code twisted together, the task was not going to be easy. "Some engineers quit over it," Barthelet says with characteristic matter-of-factness. "But there wasn't a lot of discussion. That's what had to be done." On September 20, 2001, the refactoring of The Sims Online began. While the design for the game built by Wright and Trottier would survive the technical retrofit, the underlying guts of the game had to be completely reorganized. And with the game due to ship in 2002, Barthelet knew the 50-person engineering team had only a matter of months to get the game in fighting shape. Therefore, a milestone was set: The first phase of refactoring needed to be done by Thanksgiving. "And I have to tell you, most of the time refactoring doesn't work," Barthelet warns. The odds weren't in the team's favor." Just thought you may be interested :)
Paul Watson
Bluegrass
Cape Town, South AfricaColin Davies wrote: ...can y
-
Marc Clifton wrote: concepts that any competent software engineer knows Couldn't agree more. But how many "competent software engineers" are there out there? As opposed to VB programmers who skimmed through "VB in 21 Days" on the weekend? Oops. Marc Clifton wrote: and all of a sudden he's an expert on something that in reality is very simplistic. I don't really care one way or the other if he or Kent Beck or Linus or whoever is a celebrity in their field - if they've got something valid to say then I'm interested in hearing it. Even if I think they're wrong, if it provokes myself or others into thinking about the issues, then it's worth taking the time to listen. Marc Clifton wrote: The whole concept of "refactoring" is so much BS to me. If the design and/or the implementation turns out to be poor, and it's cost effective to fix it (as opposed to rewriting it from scratch or just living with it), then fix it and make sure to test the results In other words, refactor it :-) I hate buzzwords as much as the next guy but the ideas that he talks about are good ones. I get the feeling that he's not promoting himself as the refactoring guru but has had that label thrust upon him. These ideas may be obvious to you and me and any other competent software engineer but it's been my experience that there are depressingly few people out there who really grok these ideas and if more folk start thinking about these things because somebody high profile like Martin Fowler is talking about them, well, it's about time!
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
Taka Muraoka wrote: But how many "competent software engineers" are there out there? And how many coders calling themselves software engineers ? *sigh* Elaine (slightly depressed fluffy tigress) Would you like to meet my teddy bear ?
-
Taka Muraoka wrote: refactoring Got to love coincidences. Was just reading a "behind the scenes" article on Gamespot about Maxis (guys who made SimCity, The Sims etc.) The coincidence bit was this:"The bottleneck wasn't in the design. The problem was the engineering and the architecture. "The code was like a big bowl of spaghetti that was all tangled up," Barthelet explains. "I looked at the way this game was going and said, 'Listen, we have to stop this right away. We have to cut all the code apart and figure out how to connect all the parts of the game again.'" While everyone on the team realized that the core game technology wasn't stable, Barthelet's insistence on completely reengineering the game's infrastructure was a devastating decision. "It was a difficult decision to make," he admits. "I had to look people in the eyes and say, 'Listen, we're going to stop development and begin a process called refactoring.'" A programmer is perplexed by some of the 3 million lines of code in the game. Refactoring, a programming term, refers to the process of pulling the game's underlying architecture apart and figuring out the most efficient way to reconnect each individual part. For a programming project with 3 million lines of code twisted together, the task was not going to be easy. "Some engineers quit over it," Barthelet says with characteristic matter-of-factness. "But there wasn't a lot of discussion. That's what had to be done." On September 20, 2001, the refactoring of The Sims Online began. While the design for the game built by Wright and Trottier would survive the technical retrofit, the underlying guts of the game had to be completely reorganized. And with the game due to ship in 2002, Barthelet knew the 50-person engineering team had only a matter of months to get the game in fighting shape. Therefore, a milestone was set: The first phase of refactoring needed to be done by Thanksgiving. "And I have to tell you, most of the time refactoring doesn't work," Barthelet warns. The odds weren't in the team's favor." Just thought you may be interested :)
Paul Watson
Bluegrass
Cape Town, South AfricaColin Davies wrote: ...can y
OMG! 3 million lines of code?!?! Trying to refactor something like that would scare the living crap out me! But I think he hit the nail on the head when he said that it was a "devastating decision". All that work and pain and at the end of the day, you got something that, at best, does exactly what you have right now! No wonder it's so hard to get approval for this kind of work :-)
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
-
OMG! 3 million lines of code?!?! Trying to refactor something like that would scare the living crap out me! But I think he hit the nail on the head when he said that it was a "devastating decision". All that work and pain and at the end of the day, you got something that, at best, does exactly what you have right now! No wonder it's so hard to get approval for this kind of work :-)
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
Taka Muraoka wrote: Trying to refactor something like that would scare the living crap out me! If you read the whole article though you can see it was coming (hindsight of course.) They took an already large game and tried to add-on code to make it into a massively multiplayer online game... sounds like a recipe for disaster that. A MMOG must be architeched properly right from the begining I would imagine.
Paul Watson
Bluegrass
Cape Town, South AfricaColin Davies wrote: ...can you imagine a John Simmons stalker !
-
Taka Muraoka wrote: Trying to refactor something like that would scare the living crap out me! If you read the whole article though you can see it was coming (hindsight of course.) They took an already large game and tried to add-on code to make it into a massively multiplayer online game... sounds like a recipe for disaster that. A MMOG must be architeched properly right from the begining I would imagine.
Paul Watson
Bluegrass
Cape Town, South AfricaColin Davies wrote: ...can you imagine a John Simmons stalker !
Paul Watson wrote: If you read the whole article though you can see it was coming (hindsight of course.) I did - an interesting read. Nice to see a case study where this kind of stuff actually worked. Sort of... :-) Paul Watson wrote: A MMOG must be architeched properly right from the begining I would imagine Well, any kind of software, I imagine. But few people think this far ahead, I suspect. They just write something to solve the problem at hand and only when it becomes hugely successful and thousands of people start using do they realise that the architecture isn't quite up to it "-)
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
-
peterchen wrote: Refactoring bears an important lesson: rather than throwing crap code away, and starting over, try to clean it up, fix a few bugs, clean up some more, add some feature. Rinse, repeat. In small steps, that always keep you a working product. That's so true. At the moment our product (Pharos - an acoustic tracking system) is currently evolving from a monolithic app to a componentised one, as a result of which a significant proportion of the code is being reworked. It's obvious to me that when you do this interfaces change, which causes major risk. The ability to support old interfaces and behaviour for a while (say 3 months) after the switchover reduces that risk significantly. This is even more important when there's a product release in the not too distant future. A little while ago this lesson was reinforced here when a co-worker (in our case an ex-team leader on another site!) hadn't learnt the same lesson and broke major functionality with an interface change without realising - or telling anyone. It wasn't particularly pleasant. Anna :rose: "Be yourself - not what others think you should be"
- Marcia GraeschI hope it didn't end "particulary pleasant" for him, too :rolleyes: I'm just sick that people like Fowler make thick books out of these tiny things. In the flood definitions, discussions, ideas, methods, techniques, the core idea gets lost.
skulls don't kiss a machito [sighist]
-
Joe Woodbury wrote: Since when? I rarely do rewrites like this nor has any engineer I know (though at times, it is necessary). I said includes. I didnt say that each rewrite involved deleting the file and starting over. Rewrite is a broader term than refactor, thus refactoring is more accurate for describing what is being done. Joe Woodbury wrote: I stand by my original statement that refactoring in practice is obfuscation of rewrite. It's more a specialisation than an obfuscation. Joe Woodbury wrote: Since nobody, including the people who bandy the word around like they've invented something new, And that's exactly who bandies the word around like they've invented something new... Nobody. Joe Woodbury wrote: knows what refactoring even means, it ends up meaning whatever each person thinks it means, Rubbish. Refactoring, according to the definition, means to improve the design of existing code without changing what it does. Simple as that. It's not very complicated. Joe Woodbury wrote: Incidentally, elmininating duplication is best called "eliminating duplication", why invent a new word to confuse the issue? Since eliminating duplication is just one part of refactoring. It encapsulates a lot more activities. Here are a few more, it's not an exhaustive list btw. Change bidirectional to unidirectional. Consolidate conditional expression. Extract Method. Extract Class. Replace constructor with factory method. Replace type code with state/strategy. The concept of refactoring has been around for a lot of years. It's a similar concept to the Design Patterns movement. The Refactoring movement (if you can call it that) has encapsulated a number of well known (and not so well known) refactoring patterns under a single banner. I don't understand the resistance. Cheers The universe is driven by the complex interaction between three ingredients: matter, energy, and enlightened self-interest.
Mr Morden wrote: Rubbish. Refactoring, according to the definition, means to improve the design of existing code without changing what it does. Simple as that. It's not very complicated. Refactoring is a buzz word invented by Martin Fowler and covers whatever you want it to cover. Your own list shows that. My argument is that using the word "refactoring" obfuscates what is required. IF you are trying to convince management of a course of action in general without being pinned down on what you're actually going to do, refactoring is a good word since it doesn't really explain what you will be doing and it sounds cool. (I've done this.) IF you are talking with other engineers, or attempting to create a budget, refactoring is wasting their, and your, time since it doesn't identify what is being done precisely because so many things fall under its rubic. (I ran across one list that had over two dozens items [buzzwords] in it.) (Frankly, simply saying "We'll rewrite the code" is just as useless and annoying and both are altogether too common.) Mr Morden wrote: It's a similar concept to the Design Patterns movement. The Refactoring movement And, based on my actual experience, I dislike and distrust both for many of the same reasons. Unfortunately, these "movements" are similar to religions to the adherents and make genuine discourse impossible.