Qafoo GmbH - passion for software quality
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:Author: Tobias Schlitt
:Date: Tue, 24 Jan 2017 09:11:15 +0100
:Revision: 6
:Copyright: All rights reserved
=======================================
Refactoring Should not Only be a Ticket
=======================================
:Abstract:
In this blog post I would like to elaborate a bit further on why
refactoring should never only be a dedicated task on your board. It should
be an essential part of every task you work on…
:Keywords:
refactoring, quality, sprint, tickets
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.
-- https://twitter.com/tobySen/status/783610875047505920
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.
.. note::
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.
__ /services/workshops/refactoring
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.
..
Local Variables:
mode: rst
fill-column: 79
End:
vim: et syn=rst tw=79
Trackbacks
==========
Comments
========
- Leonid Sklyut at 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.