Don't Love Your Code; Bombard it through 'Refactoring'

Refactoring is a simple engineering technique that our illustrious developers used quite successfully for decades and agile frameworks like xP adopted it to make it an unavoidable tool in the kit of agile developers. But of late, I have a doubt running over my mind whether the new entrants to development accord the same importance to refactoring like their seniors did. I wouldn't put the blame immediately on them though some people may be guilty of not doing it despite understanding the value it brings to the product. Poor education could be one  reason for that.

Impact of Software Frameworks

Apart from 'people and cultural' reasons, there may be others as well. Emphasize on higher productivity and lower cost  by the customers and managers resulted in the evolution of 'near turn-key' solution frameworks and software factories. The obvious result was too much production of auto-generated code that comply itself to a pre-determined architecture, foreseeable structure  and familiar design patterns. Example - ASP.NET MVC project templates.

The moment you choose the project template, your IDE creates the entire solution blue print even with minute configuration details and a hell lot of code. This is great in more than one way- like high productivity, low cost, rapid GTM and even a young development team can scale up to a standard. Down side is nobody thinks it's their code, 'It's my code' pride is gone. Developer's role is limited to mere fillers of code snippets (worse, most of the times even that was googled out) inside the method boundaries. Method signatures too designed by the IDE in most cases.

But this shouldn't be an excuse for NOT refactoring. Refactoring by definition means 'making small changes to internals of the code without changing the externals as and when more clarity on requirements becoming available'. And you do refactoring for engineering reasons rather than functional reasons.

That means you don't need to make revolutionary changes to your code or design, but subtle and simple changes that eliminate duplication, improve readability and maintainability, make the code more tidy and handle logics more efficiently. It's a much more effective practice than the peer-to-peer code reviews, because nobody understands your code better than yourself. To refactor, you need to live with your code for sometime at least just like a poet does with her poetries.

One emotional factor that prevents people from refactoring their code is why should I touch a running code and 'I cannot see my working code being changed for some frivolous reasons'. That's where we need to become less emotional and stop loving our code. We should not hesitate to break a long running code, be bold enough to make it better while seeing that it continues to support the same features as before refactoring.

Have the following in mind while attempting to refactor

• Do refactoring only for enhancing engineering aspects and NOT to add any features
• Check after refactoring if the number of lines of code reduces.
• Check after refactoring if the code becomes simpler. While the last 2 ones are not a must, you generally expect it out of refactoring. Of course simple design/code is difficult to achieve
• You MUST have a set of solid unit tests before plunging into refactoring. Unit tests are such an important cog in your engineering plan
• Most obvious, do not attempt refactoring if you are near to a release schedule
• Don’t try this immediately after coding a feature; it should be done over a period as the requirements and code evolve. You will have a better clarity and new ideas by then