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.