I try not to miss them, but the last .Net user group was about refactoring. I’ve been refactoring before I wrote unit tests, which was very courageous (and stupid). 

This post is a response to Gadi Meir’s post (in Hebrew) in which he states that refactoring policy should be defined by the CTO or equivalent. It’s  not  a do or don’t policy – rather the style, which should be derived from the organization’s coding guidelines.

Having been in charge of writing and checking these guidelines in the past I can tell you that in my case, they weren’t effective. I know organizations that live by it, entering tools like FxCop into their build system, and automate the guidelines check.

Take it one step further, and you get refactoring guidelines. It can work out, or it can crash and burn.

The most effective tool in development is peer code review. This is where one developer explains, persuades and communicates his work to another person. Refactoring is part of that translation, where you sometimes negotiate with your peer about what the code should look like.

And this is where I go against the guidelines. Having been there, the guidelines were there to keep things simple and readable (at least I hope). But that should never trump the ability of two or more developers to agree about what the code should look like. Because at that point both developers agree that the code reflects the intent, it reads well, and when a new developer comes, she’ll be able to go into the code with no problem. And they use refactoring to get there.

Individuals and interactions over processes and tools. (from the Agile Manifesto). Refactoring for everyone!