Ramblings on code refactoring

As a Telerik employee I use Visual Studio and JustCode (JustCode is a Visual Studio productivity tool which provides code analysis, navigation, refactoring and other goodies). I often refactor my code with the help of JustCode. However over the years I had become more careful and in a way more reluctant to code refactoring. I will try to write down my thoughts and explain what I mean.

I don’t buy entirely the idea that we are mere mortals and we will never be able to write “perfect” code. I think that most of the developers do a good job and they strive to write the best code. During the project they get more domain knowledge and it is expected that they want to improve the existing code. So they do refactor their code. Especially if there are good unit test suites to prevent regressions. Sometimes there is no need for refactoring – the code is good enough. Yes, this also happens 🙂 Sometimes we write bad code and we refactor it.

I also don’t buy the idea that the developers do code refactoring only for the sake of it. Junior developers may be tempted by powerful tools like JustCode that allow very easy code refactoring, but there are rare cases. Most of them are reasonable guys and they do code refactoring only when there is a need for.

Still my observations are that immediately after code refactoring the number of bug increases. You can easily check this by observing projects on sourceforge.net, codeplex.com and so on.

I think the reason for this lies in the lack of conveying the change in the mental model together with the code refactoring. In a team of 10 or more software developers each one updates its mental model spontaneously and it hard to keep all the developers in sync. Maybe that’s why code refactoring works more smoothly in small teams. In the small teams the communication is much simpler and it is easier to have a shared mental model.

That’s why every time before I commit a code refactoring in the source code repository I think how I am going to communicate the change to the other team members.