Talk:Refactoring
| Line 2: | Line 2: | ||
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>. [[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>. [[user:Lindsay | Lindsay]] | ||
| + | |||
| + | Added some of the refactoring methods. More to come. -- [[User:Jason Clutterbuck|Jason Clutterbuck]] 11:19, 20 September 2008 (UTC) | ||
Revision as of 11:19, 20 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. Lindsay
Added some of the refactoring methods. More to come. -- Jason Clutterbuck 11:19, 20 September 2008 (UTC)
