Refactoring 101
-
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
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! Yes--this is true! You make your points very well. Not to digress, but... Unfortunately, in my experiences, it isn't the code jocks that really need to learn this lesson. It's management. I have often been turned down when requesting budgeted time to refactor some code. It usually ends up that some other customer pays for the refactoring or its folded in to the next revision (folded in, meaning for the most part, ignored both in terms of time and dollars). Somehow, management has classically demonstrated a complete lack of understanding that code is an investment. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
-
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: 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.
-
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! Yes--this is true! You make your points very well. Not to digress, but... Unfortunately, in my experiences, it isn't the code jocks that really need to learn this lesson. It's management. I have often been turned down when requesting budgeted time to refactor some code. It usually ends up that some other customer pays for the refactoring or its folded in to the next revision (folded in, meaning for the most part, ignored both in terms of time and dollars). Somehow, management has classically demonstrated a complete lack of understanding that code is an investment. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
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
-
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.