Refactoring in times of Agile
Hi! I am Ignacio and I had the pleasure to join Skello recently as a Software developer.
During the onboarding, I took part in a meeting that particularly caught my attention. Its name is Lean Coffee. It is an optative, open space for all devs to come together and discuss about diverse topics for which we want to debate and gather colleague’s opinions.
The ultimate goal of these sessions is to detect points of improvement and finding ways to facilitate our daily work.
One of the topics we discussed about was refactoring, specifically how we could work on our daily tasks, taking time for finding improvement opportunities and actually applying them, without neglecting the time to delivery.
Having found myself very fond of refactoring these last years, I’d like to reflect on this by referring to one of my favourite Software Engineering books: Clean Code by Robert C. Martin.
From the many values I found on this book, I keep remembering the so called Boy-Scout rule
“Always leave the campground cleaner than you found it.”
Translated to code, this means that we should always be observant of improvement opportunities to keep our code clean*.*
How many times, while working on legacy code, have we found ourselves confused about the responsibility of some function, or the meaning of a variable name? It doesn’t necessarily have to be code written by someone else; even code written by us time ago can be challenging if the naming is poor and the actions unclear.
People use to associate refactoring with this big replacements of simple-although-not-so-clean code into this sophisticated showcases of design pattern expertise. These can be intimidating sometimes because of the complexity they can add to the code and the opportunities to introduce regressions.
While these big changes are necessary sometimes, there’s also plenty of refactoring options that are way simpler, less risky and that can boost our job’s and code quality of life.
Did we find ourselves struggling with what a method does? Let’s rename it and make it obvious! Did we stumble across a method that had way too much responsibilities? We can always extract them into new, smaller methods or delegate them to new classes or modules. Our team mates and our future selves will be thankful!
These small yet powerful changes also help communication among colleagues and onboarding. By making our code clean enough, simple and explicit, there’s less friction to understand and it takes less time to be able to work with it.
Needless to say, to be confident that we don’t introduce regressions with our changes, we should always look forward to having our code tested. Bonus points if the code was Test-Driven 😄
The Boy Scout rule implies that refactoring should not be aside a task; but part of it. Features themselves are not the only value we can deliver; constantly improving our code too, as it helps us keeping projects easy to maintain, potentially preserving them alive for a long time.
So, to finish, I would like to tell something that has worked for me, taking all of this into account. When estimating a task, we can consider the effort it will take, plus some extra story point/s to reflect our work while refactoring to be responsible, diligent Scouts.
Ignacio — Full Stack Developper Senior — Barcelona