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...) |
Brett Ward (Talk | contribs) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| 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>. [[user:Lindsay | Lindsay]] | ||
| + | |||
| + | Added some of the refactoring methods. More to come. -- [[User:Jason Clutterbuck|Jason Clutterbuck]] 11:19, 20 September 2008 (UTC) | ||
| + | |||
| + | Found refactoring.com and added it to See Also. More information than I can process right now so I will stick with reading the book -- [[User:Jason Clutterbuck|Jason Clutterbuck]] 21:56, 20 September 2008 (UTC) | ||
| + | |||
| + | Finished adding the links for each refactoring from the text book. The book is a good read. I will make time to write up some explanations in the coming week. --[[User:Jason Clutterbuck|Jason Clutterbuck]] 06:34, 21 September 2008 (UTC) | ||
| + | |||
| + | ---- | ||
| + | |||
| + | Took some time putting a bunch of basic outlines on pages that have yet to have been added (still adding more as I write this). A lot of the refactorings really don't need a lot of explanation, but I'd rather have the basics than a dead link. Might also be worthwhile adding examples to the various outlines at some stage, too. A lot of the stuff has been reworded/expanded upon from the refactoring.com pages. -[[User:Brett Ward|Brett]] 21:39, 14 October 2009 (UTC) | ||
Latest revision as of 21:39, 14 October 2009
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)
Found refactoring.com and added it to See Also. More information than I can process right now so I will stick with reading the book -- Jason Clutterbuck 21:56, 20 September 2008 (UTC)
Finished adding the links for each refactoring from the text book. The book is a good read. I will make time to write up some explanations in the coming week. --Jason Clutterbuck 06:34, 21 September 2008 (UTC)
Took some time putting a bunch of basic outlines on pages that have yet to have been added (still adding more as I write this). A lot of the refactorings really don't need a lot of explanation, but I'd rather have the basics than a dead link. Might also be worthwhile adding examples to the various outlines at some stage, too. A lot of the stuff has been reworded/expanded upon from the refactoring.com pages. -Brett 21:39, 14 October 2009 (UTC)
