Tuesday, May 13, 2003

trackback []

Re-Factoring vs Don't Tinker with Functioning Code Bob Cringely writes “against” refactoring, adducing the well-known principle that “if the code ain’t broke, don’t fit it”. Hard to argue with that. But when I think of re-factoring, I think of another hard-to-argue-with aphorism: “take the time to do it right”. So, no, you shouldn’t dive into an ugly section of code if it is bug-free and not affected by any feature enhancement requests. But if either of the following scenarios apply, then you do have a re-factoring opportunity: You have to make a minor update to existing code, like maybe add some “ElseIf” statements to exclude some previously unforeseen exceptions. Following the rule of 3 for refactoring, maybe it is time to create a more generalized, configurable case that could eliminate future maintenance of this sort. Either way, the module will have to be re-tested. Similarly suppose you are making an update to existing code, and in an adjacent section within the same module, you see a section of code that presumably works but is problematic. Perhaps it doesn’t conform to current standards (because SQL statements are hard-coded rather than assembled dynamically), and could break in the future if there is a seemingly innocuous change to the database. The entire module has to be re-tested anyway, so seems like a good time for a well-chosen re-factoring. 9:47:32 AM    comment []