ArticleS. PaulPagel.
PreFactoring [add child]

Prefactoring




Prefactoring is when you see a piece of code which the story you are working on which has a refactorings which would make your story easier. I have seen prefactoring to be a dangerous process. On one hand, you save time when you know that this refactorings will need to be done. You are faced with the choice of writing temporary code (in the sense of duplicate then refactor) or refactoring, then writing quality code. The software designer in me always wants to choose the prefactoring solution, since it gets to make code cleaner, remove duplication, and be more efficient. Then I can stand on the mountain top waving my flag.

There are a few problems right off the bat. First, the uber-developer in all of us will refactor as much as we can, therefore refactor based scope creep is bound to show up. I don’t really know how to stay away from scope creep in this manner.


Prefactoring can lead to a version of design up front which is detrimental if you don’t need it. However, sometimes you know up front this design simplification will cut the story time in half. Do you prefactor? What kinds of smells make it ok or terrible to prefactor?


I have tried backing my way in and using test(s) as a life jacket, so once the test passes, the refactoring is done. However, the problem with this is it leaves me with half done refactorings. The code is constantly moving up in quality, however, it might not look it due to the inconsistencies produced by half done refactorings. I generally think of a complete refactorings as something that made my system better in some manner I would like developers who are extending the behavior of the system to use the refactorings as a model.


Do my refactorings make the system easier to extend? Half-factorings don’t, but they do provide a manageable slope moving positive. I don’t have the time to tackle the big refactorings, but I don’t want to leave them unfinished.





!commentForm

 Wed, 22 Mar 2006 09:27:50, Uncle Bob, Half-factorings
Paul,
Keep the code clean! If the tests pass when the refactoring is half-done, then complete the refactoring. If you can't complete the refactoring in this iteration, then keep putting effort into it during subsequent iterations. Make sure the team knows, so they can put some effort in too.

There are often times when a new story is easier to implement in a structure different from the one that exists. Refactoring (or "pre-factoring") the system into that new structure to make that story easy to implement is often a good approach. However, leaving the refactoring in a half-finished state is messy.
 Wed, 22 Mar 2006 18:30:36, Micah Martin, Prefactor
Prefactor - I like that. If I counted all the time I've had to delete my prefactored code.... I believe there's an Big Up Front Designer in all of us. Face it, BDUF is fun! Frequently I look at a prefactoring that I've just completed and realize I've been BDUFfing. Most of the time I delete it all because it's too complex and unnecessary.
 Sun, 23 Jul 2006 08:14:08, Sebastian Kübeck, BDUF
To be honest, I never got BDUF right. Untill today, I need to start over one to four times untill I get what I want.
I was convinced that I'm just lacking the skills to get it right the first time.
Fortunately, I found out that people that are much smarter and much more experienced than me don't get it right the first time either.

I learned in school that Mozart just wrote down his music which was already completely finished in his head. I was toled later that this is just another myth about this guy. Beethoven permanetly adapted his works. His handwritings are hard to read because his corrections. Bach adapted his works depending on the number of musiciants he could afford.

Conclusion: If not even the geniuses mentioned above get it right the first time, how should we "ordinary people" should ever be able to do it?