Talk:Refactoring
(New page: I'm doing lots of refactoring here today. It occurred to me that an important property of refactoring is not "going out on a limb", so that you're <b>always</b> in a position to run the ap...) |
|||
| Line 1: | Line 1: | ||
I'm doing lots of refactoring here today. It occurred to me that an important property of refactoring is not "going out on a limb", so that you're <b>always</b> in a position to run the application in all it's unbroken glory. This is in contrast to those furtive, secret sessions in which we completely rewrite a whole lot of code over night (perhaps at home) then slip it into the code base the next morning before other people get to look at it. Refactoring is where you're always ready for when the boss walks in unexpectedly and demands a demo. Not like just then, when I had to say "um, well...". [[user:Lindsay | Lindsay]] | I'm doing lots of refactoring here today. It occurred to me that an important property of refactoring is not "going out on a limb", so that you're <b>always</b> in a position to run the application in all it's unbroken glory. This is in contrast to those furtive, secret sessions in which we completely rewrite a whole lot of code over night (perhaps at home) then slip it into the code base the next morning before other people get to look at it. Refactoring is where you're always ready for when the boss walks in unexpectedly and demands a demo. Not like just then, when I had to say "um, well...". [[user:Lindsay | Lindsay]] | ||
| + | |||
| + | Another though, since it's so dear to my heart at the moment..if we're developing a bit of software, adding features as the client dreams them up, then we must be refactoring <b><i>sometime</i></b> because nobody can anticipate everything in advance and come up with a totally future-proof design. If we did, then that design would have to be inappropriate at some stage of the lifecycle of the product wouldnt it, IE. not responding to the forces pushing on it (see Christopher Alexander and his organic designs). So, facing the inevitable, we should allocate some special, regular time for our refactoring, maybe after a release, when we can breath easy and be creative. And we should explain the need for it to management, who often forget it's importance..be staunch, stick up for your <b>refactoring me-time</b>. | ||
Revision as of 23:32, 16 September 2008
I'm doing lots of refactoring here today. It occurred to me that an important property of refactoring is not "going out on a limb", so that you're always in a position to run the application in all it's unbroken glory. This is in contrast to those furtive, secret sessions in which we completely rewrite a whole lot of code over night (perhaps at home) then slip it into the code base the next morning before other people get to look at it. Refactoring is where you're always ready for when the boss walks in unexpectedly and demands a demo. Not like just then, when I had to say "um, well...". Lindsay
Another though, since it's so dear to my heart at the moment..if we're developing a bit of software, adding features as the client dreams them up, then we must be refactoring sometime because nobody can anticipate everything in advance and come up with a totally future-proof design. If we did, then that design would have to be inappropriate at some stage of the lifecycle of the product wouldnt it, IE. not responding to the forces pushing on it (see Christopher Alexander and his organic designs). So, facing the inevitable, we should allocate some special, regular time for our refactoring, maybe after a release, when we can breath easy and be creative. And we should explain the need for it to management, who often forget it's importance..be staunch, stick up for your refactoring me-time.
