Comments on: Code refactoring VS feature addition. http://osric.com/chris/accidental-developer/2008/03/code-refactoring-vs-feature-addition/ What if Gregor Samsa awoke a computer programmer? Tue, 24 Jan 2012 03:45:08 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: sprender http://osric.com/chris/accidental-developer/2008/03/code-refactoring-vs-feature-addition/comment-page-1/#comment-9 sprender Fri, 28 Mar 2008 06:50:03 +0000 http://osric.com/chris/accidental-developer/?p=11#comment-9 Unfortunately, many businesses don't think long term, which is an important part of the argument for refactoring. The other part, which is easier to sell, is about being agile. Perhaps most importantly, cleaner code makes a developer's life suck less. Do it for your own good, if you can get away with it, even if your employer doesn't care. Assuming you get repeat business from that client, wouldn't you rather spend your time programming features that actually help their business or would you rather put out fires in their brittle infrastructure all day? In the latter case nobody wins. Therefore, occasionally it is best to respectfully use your own judgment and then allow the results to speak for themselves later. However, you can definitely get away with refactoring code and adjusting UI simultaneously (or even business logic), but you need a decent strategy to mitigate the risk of breaking things. I tend to rely on the refactoring tools, which are built into all the good IDEs now, in order to keep things clean. Historically this required regular expression acrobatics to find and replace across files, but now you can do a lot of things like rename functions & variables, adjust method signatures, or even extract interfaces (for those who like MVC and other design patterns) all without worrying about fixing up all the dependent code. Plus, I know you're a big advocate of version control so you're already checking your own work there via diffs (amen to Chris' advice in his earlier post btw). Unfortunately, many businesses don’t think long term, which is an important part of the argument for refactoring. The other part, which is easier to sell, is about being agile. Perhaps most importantly, cleaner code makes a developer’s life suck less. Do it for your own good, if you can get away with it, even if your employer doesn’t care. Assuming you get repeat business from that client, wouldn’t you rather spend your time programming features that actually help their business or would you rather put out fires in their brittle infrastructure all day? In the latter case nobody wins. Therefore, occasionally it is best to respectfully use your own judgment and then allow the results to speak for themselves later.

However, you can definitely get away with refactoring code and adjusting UI simultaneously (or even business logic), but you need a decent strategy to mitigate the risk of breaking things. I tend to rely on the refactoring tools, which are built into all the good IDEs now, in order to keep things clean. Historically this required regular expression acrobatics to find and replace across files, but now you can do a lot of things like rename functions & variables, adjust method signatures, or even extract interfaces (for those who like MVC and other design patterns) all without worrying about fixing up all the dependent code. Plus, I know you’re a big advocate of version control so you’re already checking your own work there via diffs (amen to Chris’ advice in his earlier post btw).

]]> By: chris http://osric.com/chris/accidental-developer/2008/03/code-refactoring-vs-feature-addition/comment-page-1/#comment-6 chris Tue, 25 Mar 2008 20:05:10 +0000 http://osric.com/chris/accidental-developer/?p=11#comment-6 I think that focusing on code and interface separately sounds like a good idea, and the fact that you can consider them as separate tasks shows that you've done a better job than most of separating the business logic from the presentation. Clients definitely want to see changes, though--if they check up on the progress frequently, then I suppose it is important to have a few obvious UI updates. I think that focusing on code and interface separately sounds like a good idea, and the fact that you can consider them as separate tasks shows that you’ve done a better job than most of separating the business logic from the presentation.

Clients definitely want to see changes, though–if they check up on the progress frequently, then I suppose it is important to have a few obvious UI updates.

]]>