Fix your code now

Not everyone writes software that can stand the test of time. It is difficult, mainly because you can never be certain you are doing a good job until you actually have to maintain or debug the code yourself.

In order to write well-structured code right from the start, you would need to know every single detail about the feature beforehand. However, as we all know, requirements often change a lot along the way during development.

One of the best gifts you can give yourself and your colleagues is what I like to call Just-In-Time (JIT) Refactoring. The idea is simple. Say you’re working on switching between tabs in your new tab switcher. Follow these steps:

Make it work. Consider refactoring.

Simple, right?

Some developers think about refactoring as fixing and improving code in legacy code bases. Wrong. Wrong. Wrong. Fix your code now and you will eventually remove the need for refactoring in the future.

It is rarely the case that the first draft of your code is well structured and you will often need to re-iterate to make the code acceptable. Notice that you should consider refactoring as soon as your feature is done, but you should also take into account if it really is needed, as you could end up over-engineering and over-abstracting simple things.

Know what to refactor with the 3Rs

Not all code needs refactoring. Knowing what to refactor comes with practice, but you can take a systematic approach to help you with the decision making by considering the following attributes of the code:

Readability : If you scan through the code, is it full of one-liners with ternary operators or nested conditionals that no human will understand? If so, it is probably not easily readable and needs refactoring.

: If you scan through the code, is it full of one-liners with ternary operators or nested conditionals that no human will understand? If so, it is probably not easily readable and needs refactoring. Repetitiveness : Repetition is a real productivity killer, mainly because when requirements change or a bug pops up, you will need to spend time adjusting the code in more than one place. In such cases, consider extracting repetitive code into a single method.

: Repetition is a real productivity killer, mainly because when requirements change or a bug pops up, you will need to spend time adjusting the code in more than one place. In such cases, consider extracting repetitive code into a single method. Reusability: Can the code that you wrote be easily reused in other places or by other developers on the team? Can you make it reusable with little to no effort by making small adjustments to the code? If so, refactoring is a no brainer, as it will boost your team’s productivity more than you realize.

Of course there is more to code quality than the 3Rs, but just thinking about it will force you into early improvements of the code structure, which will in turn add to your and your team’s velocity.