By Tobias Schlitt, first published at Tue, 24 Jan 2017 09:31:30 +0100
Download our free e-book "Crafting Quality Software" with a selection of the finest blog posts as PDF or EPub.
You can also buy a printed version of the book on Amazon or on epubli.
A while ago I tweeted
#Refactoring should never only be a dedicated task on your board. It should be an essential part of every other task you work on.
In this blog post I would like to elaborate a bit further on what I mean and why I think this is important.
When we do quality workshops and trainings on-site at our customers we see various approaches to refactoring which typically fail, for example:
A general ticket "Refactoring" is added to every sprint
Dedicated refactoring sprints are requested
The problem here is that refactoring is not seen as an essential part of the daily work, but instead as a dedicated task that requires additional time on top of daily work.
Compare your work as a programmer to the job of any type of craftsman: does that craftsman charge additional time for cleaning up the construction site? Of course not. Either you clean up your working place after finishing a task or you need to do it before starting the next. Both ways are possible, but just skipping to clean your workplace until you get dedicated time is not an option.
This is exactly the way how you should approach refactoring: When starting a new task you need to analyze the existing code anyway. If you stumble over some dirt, clean it up as you go. When you finished your task reflect what you just did. Maybe a method grew too large? Maybe you could avoid duplication? Maybe you chose a bad name? Fix it – now!
If your team accepts refactoring as an essential part of every work they perform, you will experience how fast your code base will improve at exactly the places you work on a lot.
Qafoo experts can kick-start your team with a continuous refactoring process. We can show you how to improve your source code quality on the go and help you to get rid of the big quality chuckholes in your construction site.
Of course you will still discover bigger challenges while trying to clean up the construction site. There will be steps which turn out to be too large to be done on the go. These are exactly the parts which should be made dedicated tickets. But beware to just name a ticket "Refactoring". Be specific instead and explain exactly what needs to be achieved to put the team in a better position to clean up on the go.
Stay up to date with regular new technological insights by subscribing to our newsletter. We will send you articles to improve your developments skills.
Leonid Sklyut on Sun, 02 Jul 2017 02:51:27 +0200
There is one exception to this rule which I'd like to note from my experience. During the Code Review process, it may be pointed out that the implementation could be refactored for any number of reasons (readability, extensibility, etc). This is an important piece of feedback to address, although the rest of the team may be expecting the feature in the PR so that they may include it in their work. In the interest of moving forward, the team member may create a ticket for the piece of feedback so that it does not block the PR. Generally, I have seen these tickets pulled into the sprint immediately and completed as the next item on that developer's todo list, after the original PR is merged. I do believe that this could get out of hand if you allow a growing number of refactoring tickets in the backlog. However, depending on the level of discipline within the team, this approach could be used to maintain momentum within the project.
Link to comment