Frontend Quick Tips #10 Refactor - How to Find the Time for It?

Those may be some patterns explained in JS code on real-life examples or some techniques for better code.

Problem:

Your project is in bad shape but there is no time for refactor and the client doesn't want you to work on it since he pays you to do your job.

Solution:

There is no clear solution as every case is individual BUT there are several guidelines to have in mind.

A refactor is not a Jira task

Just like tests in your codebase - refactoring is a process that should be implemented in your feature workflow. Just as you work on understanding and coding a feature, then you have to write tests and refactor your code so it’s readable. Only after that is your task done. Just because your feature works it doesn’t mean that the task is done.

Task description → Development → Write tests → Refactor → Done

Remember to include tests and refactoring in your task estimations!

The power of “no”

You are a professional developer and even though you’re not your code - you are responsible for it. You have to maintain and build the best possible architecture - no matter if you’re a senior or a regular dev. Clients pay us to be professional and sometimes it means we have to say “no” as we are aware of the consequences of building a bad app architecture. You are the guard of the codebase.

Remember - your client has his own business goals to fulfil and those usually are features. You have to keep the balance of filling the business requirements and keeping the right architecture.

…but there is so much to do! We will have to spend like a month doing an actual refactor! The client will never accept it.

He probably won't', but that’s not a reason to give up.

• Split your refactor to smaller chunks - you don’t have to do everything at once! It’s better to be inconsistent with your architecture for some time because you are implementing changes than do nothing.
• Talk to your PM/Leader - Let them know the project is in bad shape and you can both start working on it. Maybe the PM can better explain to the client how important a refactor is? (That previous scope produced a different architecture and now you have to adjust?). They are here to help you.
• Whenever you enter some legacy function - leave it a better place (scout rule). I know you didn’t create it. I know you were working on something else, but if you will pick up one piece of trash every time you enter the woods, you will clean up the whole area. Just don’t get lost in the refactoring.

Tests are your ally!

So you want to refactor? Cool, but remember you can’t break the program during that process, so first of all ensure you have a reasonable amount of tests before proceeding. Sometimes a bigger refactor starts with more e2e coverage to ensure app stability for the business.

Note:

There are cases where a refactor has to be postponed - you have a deploy coming up or something has to be done ASAP (like some urgent fixes to the production).

Refactors are important, but not urgent.

Bonus:

here is a graph from https://xkcd.com/1205/ showing how much time your refactor would gain you (based on how often you work on a task).