Refactoring 101
-
Taka Muraoka wrote: Martin Fowler Damn how little I know... I thought you were talking about that young lad from Eastenders[^]! :-O
David Wulff http://www.davidwulff.co.uk
David Wulff Born and Bred.
David Wulff wrote: I thought you were talking about that young lad from Eastenders[^]! Good grief! Is that *still* on?! The show that will never die. A bit like Neighbours here... :-)
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
-
Marc Clifton wrote: it isn't the code jocks that really need to learn this lesson. It's management. You can't really blame them for that, though. They can't help being what they are :-) Seriously, it's hardly surprising they don't understand the deeper issues here. Software engineering, good software engineering, is something that takes years of study and experience. As does management, for that matter. If I was put in charge of a project that I didn't really understand, say building a house, and the builder came to me and said that he wanted 2 weeks and $10,000 to do something that didn't, to me, add any immediate value, I'd probably say no as well. Marc Clifton wrote: Somehow, management has classically demonstrated a complete lack of understanding that code is an investment. So then it's our job as People Who Know Better to assist and educate our managers about these issues and articles like this one are a good way of doing that: "Look at this. Martin Fowler is a really well-respected guy in the industry and he says that refactoring is a Good Thing (tm)." Do a cost-benefit analysis of the refactoring work you're proposing - nothing hits home better with a manager than a problem with the bottom line. Do a cost-benefit analysis *after* things have f*cked up. Upwards management, it's the name of the game :-)
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
to do something that didn't, to me, add any immediate value, I'd probably say no as well. So then it's our job as People Who Know Better to assist and educate our managers about these issues This is where I disagree. I am hired specifically because of my expertise, yet when I request (with a cost benefit analysis) a time/dollar committment that must be paid for as an "R&D effort", then suddenly my expertise is in question. Instead of being up front about budget problems (or the complete lack of an R&D budget!), I end up feeling that there are trust issues between myself and management. I have worked with a couple really good managers that have either trusted me implicitly (and that trust extended to my being able to say "I f*cked up") or at least asked intelligent questions. That's the job of a management (to facilitate), and no amount of education by the pions can change that if you have a bad one (which I've had too). It is literally easier and less stressful to find another job instead (or another manager. I did that once, and it was wonderful, for all involved). Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
-
Well, here we see again someone who has taken a bunch of kindergarten concepts, concepts that any competent software engineer knows, gives them a fancy name, writes a fancy book, and all of a sudden he's an expert on something that in reality is very simplistic. 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. That's it. What else is there to say on the subject? Sorry if I have caused offense. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
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]
-
to do something that didn't, to me, add any immediate value, I'd probably say no as well. So then it's our job as People Who Know Better to assist and educate our managers about these issues This is where I disagree. I am hired specifically because of my expertise, yet when I request (with a cost benefit analysis) a time/dollar committment that must be paid for as an "R&D effort", then suddenly my expertise is in question. Instead of being up front about budget problems (or the complete lack of an R&D budget!), I end up feeling that there are trust issues between myself and management. I have worked with a couple really good managers that have either trusted me implicitly (and that trust extended to my being able to say "I f*cked up") or at least asked intelligent questions. That's the job of a management (to facilitate), and no amount of education by the pions can change that if you have a bad one (which I've had too). It is literally easier and less stressful to find another job instead (or another manager. I did that once, and it was wonderful, for all involved). Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Marc Clifton wrote: yet when I request (with a cost benefit analysis) a time/dollar committment that must be paid for as an "R&D effort", then suddenly my expertise is in question. Been there as well :-( But it depends how they say no, though. If they have listened to your advice but decide not to spend the money, well, that's their decision and (hopefully) their responsibility. But if they're paying you for your expert advice and then not listening to it, well that's just silly. And their loss. I learned to stop caring about situations like that a long time ago. I've done my job, made my recommendations; if you choose to ignore them, that's up to you. As long as I get paid, you can do what you want :-) Marc Clifton wrote: That's the job of a management (to facilitate), and no amount of education by the pions can change that if you have a bad one (which I've had too). Amen to that. If your boss isn't listening, their ain't nothing you can do 'bout that.
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
-
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]
Rinse, repeat. In small steps, that always keep you a working product. Well, it takes a real expert, and I certainly don't profess to be one, to know when something is stable enough that it can go through the wash cycle, or whether it should be given to the Salvation Army. Naive management can get in the way--"why can't you just re-use some old code, isn't that why I invested in all this object oriented hoopla to begin with???" and a programmer's desire to always re-invent the wheel ("it'll roll faster this time") can also get in the way (this is my particular devil that I always fight with). It seems to me (looking at Windows, for example), that instead of "rewrite for the better", we have the "rewrite just enough to get it to market" philosophy. I've been in that situation myself, and it sucks (both as an employee and as a consultant to meet the demands of a client, or a fixed budget). But I must say, Microsoft must do enough of the "good" kind of refactoring, because they have this huge code base and it all hangs together amazingly well. At least I can write an invoice without Word crashing! But hey, that's what all those Service Packs are for, now isn't it? Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
-
David Wulff wrote: I thought you were talking about that young lad from Eastenders[^]! Good grief! Is that *still* on?! The show that will never die. A bit like Neighbours here... :-)
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
Eastenders isn't going anywhere anytime soon as unlike Neighbours they have strong (and understandable ;)) actors. :rose:
David Wulff http://www.davidwulff.co.uk
David Wulff Born and Bred.
-
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: 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
-
Marc Clifton wrote: yet when I request (with a cost benefit analysis) a time/dollar committment that must be paid for as an "R&D effort", then suddenly my expertise is in question. Been there as well :-( But it depends how they say no, though. If they have listened to your advice but decide not to spend the money, well, that's their decision and (hopefully) their responsibility. But if they're paying you for your expert advice and then not listening to it, well that's just silly. And their loss. I learned to stop caring about situations like that a long time ago. I've done my job, made my recommendations; if you choose to ignore them, that's up to you. As long as I get paid, you can do what you want :-) Marc Clifton wrote: That's the job of a management (to facilitate), and no amount of education by the pions can change that if you have a bad one (which I've had too). Amen to that. If your boss isn't listening, their ain't nothing you can do 'bout that.
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
As long as I get paid, you can do what you want Ugh. I've learned I just can't go there. I can't live with other people's stupid decisions, especially as a salaried employee. Now, as a consultant, I just factor in an adjustment for stupidity that causes me extra work. Time is an irreplaceable commodity, after all. :-D Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
-
As long as I get paid, you can do what you want Ugh. I've learned I just can't go there. I can't live with other people's stupid decisions, especially as a salaried employee. Now, as a consultant, I just factor in an adjustment for stupidity that causes me extra work. Time is an irreplaceable commodity, after all. :-D Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Marc Clifton wrote: I've learned I just can't go there. I can't live with other people's stupid decisions Yeah, but the reduced stress means that I'll probably live longer :laugh: There's a lot of stupid people out there making stupid decisions. I read a quote somewhere ages ago that I really liked: banging your head on a wall is a waste of time: it doesn't affect the wall and just gives you a headache. It's just a job.
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
-
Marc Clifton wrote: I've learned I just can't go there. I can't live with other people's stupid decisions Yeah, but the reduced stress means that I'll probably live longer :laugh: There's a lot of stupid people out there making stupid decisions. I read a quote somewhere ages ago that I really liked: banging your head on a wall is a waste of time: it doesn't affect the wall and just gives you a headache. It's just a job.
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
It's just a job. Not for me. It's a passion. Hence I get emotionally involved. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
-
It's just a job. Not for me. It's a passion. Hence I get emotionally involved. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Oh, me too. But the stuff I do Monday to Friday to pay the bills, that's just a job.
I'd wear a miniskirt and pimp myself for an extra ten grand a year. - David Wulff
-
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