The hidden costs of a Refactoring

Looking over our oldest C++ code, there is, of course, a lot of potential for Refactoring.  That’s a nice way of saying that it sucks.

We learned about Refactoring because we wanted to build good tools for our customers.  Along the way, we also realized that we wanted to Refactor, too.  One of the benefits of working on a development tool is that you get to spend a lot of time thinking about how you develop.

Normally when I think about the challenge of doing an Extract Method, I think about things like:

• Figuring out the inputs & outputs, and their types
• Making sure that the block I’m extracting has consistent exit rules
• Thinking up a good name for the new method

With a little thinking, some more costs appear:

·        In C++, the method signature must exist in both the .h and .cpp files.  They’re almost, but not quite, identical.

·        If I didn’t get the signature right the first time, I have to fix it in both places.

·        I need to check both the .h and .cpp files out of source control. 

As I start to dig in, I find even more work to do:

• My class has too many methods to manage.  I could break out a new class in the same file, but then:
• My file has too many classes.  I could break out a new file, but then
• I need to add the new .cpp file to source control, the .vcproj, and my build system.   
• I need to add the .h in the same way
• I need to include the .h in the right places
• I have too many files in the directory/project
• Now I need to create a new project, a new subdirectory to hold it, and move files around in the build system & in source control

So today I have too many files in each directory; too many classes in each file; too many methods in each class; too many statements in each method.  I’d like to refactor more, but I have to start at the other end – working on the build system & file system.

On my team we’ve focused most of our attention on what appears to be the “hard part” – getting the signature of the extracted method just right.  The rest is stuff we’re sure you can do without help.   But the truth is that all that resistance backs up & you won’t refactor mercilessly.

Integration helps.  If you use VSS (ouch!) or otherwise have your source control integrated with your C# project, then Whidbey Refactorings will check out the files automatically.  And if you use the same project file for nightly builds & IntelliSense, then you can skip a step.   Still, the cost is there.

Rename and Extract Method are the two most important Refactorings we could provide.  But before we go further, maybe we should stop and think about the integration story.  Make sure that you can get your whole project arranged well with as little effort as possible.  Imagine if creating a new class in a new project took 0 effort.  Would you refactor more?