Many articles have been written about refactoring. What I'm trying to do here is to bring to light a real-life example of how our team approached the problem, and how we planned to deal with it.
source: http://www.thebluediamondgallery.com/
A few weeks ago, I joined a certain blog project. The technology doesn't matter in this case. What will be crucial here is the code quality we found ourselves working with and the challenges we faced.
Code Quality
Code quality is something measurable. It shouldn't be just a particular developer's opinion. But we have to remember:
There is no such code which one does not rewrite better with time.
This is simply a way of saying that there is no perfect code. That's why we need criteria to determine when a piece of code is a candidate for refactoring. We also need an understanding of why we don't just refactor things without any consideration, even though we know our code is bad.
As software engineers, we are often caught in a certain mental, technical closure. We are so focused on the quality of code, features we want to deliver, and bugs we want to fix that we forget one very important thing: We should also be aware of the business layer of the project we are working on. A software engineer is someone who, except for their technical and interpersonal skills, is also taking care of the user he is working for. Features we are developing, bugs we are fixing — those things are, in the end, for our end-users. So will this refactor bring value to them?
That leads us to the criteria. We will ask ourselves questions, give them a weight and evaluate them. The format will be as follows: (weight) Question.
Given the current state of the part of the code you are working with right now:
- (5) is this code prone to bugs?
- (3) I got few bugs to fix — how much time will I spend to wrap my head around the code itself just to fix one issue?
- (3) is this code scalable? (Consider complexity with each addition and readability).
- (2) How much time will I spend refactoring this chunk?
- (2) Will this refactor expose me to risks? If so, how do I prevent them? (Scenario: complex, unclear logic along with a lack of tests and documentation)
As you can see, those questions easily relate to our end users. Either by exposing them to risks or by delaying a bug fix or new features.
Add the weights from questions with positive answers only.
For me, a sum equal to 5 is the minimum to start considering the code as a candidate for refactoring, especially, if the answer to the first question is affirmative. If the result is 7+ then, surely, you got a solid basis to speak with your team and to plan to refactor.
You may think such approach is unnecessary. After all, you are an experienced engineer, and you know when you have to rewrite certain code. While that is true, a structured evaluation is easy to present to your team. With it, you are transparent about what you do and how you approach the refactoring problem. There is no longer this shady area of "because I feel so" or "I just see this code is bad". You will also find yourself thinking more about for whom (apart from yourself) you are doing this in the first place.
Give it a try!