In 2014 I got the opportunity to attend a talk on refactoring at ThoughtWorks Uganda geeknight by Martin Fowler. I think refactoring is a powerful concept yet very simple (Martin Fowler’s book on refactoring nails in chapter 1).
I have met several developers who have brushed me off and told me their code “works” and the structure doesn't matter. Well, structure matters.
Below are my four reasons for refactoring.
1. Katogo Is Great To Eat, Not Good To Read
Katogo is a traditional dish in Uganda which consists of mixture of various numerous ingredients and I usually have eaten it for breakfast. <img src="http://www.iafrikan.com/content/images/2016/03/Katogo-Uganda.jpg" width="30%" height="30%" style="float:left; padding: 10px 10px 10px 10px; margin-right="10px";"/> I happen to like it and usually don’t turn down a plate however if your code looks like Katogo , I usually turn it down. I won’t lie I have produced my fair share of Katogo code but I saw the error of my ways. Many programming languages have the power to abstract control structures in the form of classes, if statements are like salt, too much of them leaves a bad taste in code.
2. Your Code Smells
Writing code is very similar to writing an essay. When you're writing an essay, no one submits a draft as their final copy. A draft helps you put out your arguments about something. Now that you have a draft, time to make it clear and straight to point. This is where refactoring comes in. So that when you submit your code/essay people will know what you're saying.
3. Repetition Sucks
I can’t stress this more!
Quote from the Pragmatic Programmer:
"Every piece of knowledge must have a single, unambiguous authoritative representation within a system."
4. A Matter Of Economics
Time == Money
Without refactoring, developers are always going to be in technical debt which accumulates and we all have to pay our debts. For a developer it's time and if you work for a company it's pretty much a waste of your company/clients time and money.
Adding features to a product is painful, adding developers to a new team is painful, maintaining is painful!