"When I pick up a story and start coding, I feel like there is so many things I want to deep dive into and potentially improve. When I have conversations with other senior developers, they tell me the reasons for implementing it that way and make suggestions about how we can improve it. Should I start making those changes or just finish my story?
This was the question that Leah Hou, a graduate developer asked me in our recent weekly catch ups. What a great question! I tried to explain using an analogy and I think this is worth sharing.
Refactoring; It is a big topic and a subjective one. We all know that we can get lost in a rabbit hole trying to refactor everything. But we should also be improving the code as we go. Otherwise, it will never get addressed. The answer is "It depends". But how do I explain "It depends" to a graduate developer.
Here is my attempt:
"Imagine your task is to make some scrambled eggs. You enter the kitchen and you start looking at how the kitchen is configured, where the stove is, where the ingredients are and where the utensils are. In the process, you realize that the kitchen is actually really messy. There is uncleaned utensils scattered everywhere, the fridge is empty, stove is covered with previously cooked food and garbage hasn't been taken out.
What can you do?
So you have a few options:
Option 1: Before you make scrambled eggs, clean up the whole kitchen and go buy all the ingredients you need for the week.
Option 2: Clean up the only utensils you need, buy the only ingredients you need, clean the stove and make the scrambled eggs. Don't worry about the rest. It is not your problem.
Option 3: Clean up the utensils you need, buy the ingredients you need, clean the stove and make the scrambled eggs, but let someone know about the mess or put it on your todo list to come back, investigate more and potentially clean up.
Option 4: Try and make something else to eat based on the ingredients and utensils available
Option 5: Try and make scrambled eggs from duck eggs and in a rice cooker ;)
Option 1 sounds great. Isn't it? The end result is a clean kitchen and stocked up fridge. Great outcome! But the question is how long will it take for you to do this? What if it takes too long and you have to go without eating food for that long? Is it feasible?
The reality is that there is always opposing forces involved when making decisions about refactoring. Time, deadlines, funding, project goals and other pressing issues are something to keep in mind.
I would ask myself these questions before making any decision:
How small is the task at hand?
How big is the refactor?
What benefits would the refactoring provide?
Is the problem that we are trying to solve on the priority list of the company? a.k.a Are there more pressing problems that we should be addressing right now?
Why did the previous developer write it in a certain way?
Is it working at the moment?
Have they had any issues due to the way it is written?
How much effort was involved previously in testing these?
If I refactor, does it affect the critical or non critical path of the business?
How long will the new change take to make it to production? Consider approvals, testing, release management etc?
From my experience, I prefer to go with option 3, i.e clean up as much code as you need to, to achieve the task in hand. Do not add to the complexity. But record the things you discovered, create a story, put it on the tech debt list and address a few of those every sprint! In this way, we are always leaving the codebase better than we found it. #IterativeImprovements #ScoutRule
What do you think? What do you prefer to do in your code base?
Comentários