4

I want my team to do refactoring as often as it is possible, and follow some guides from Martin Fowler book. Although I'm confused about something:

If we use scrum or kanban and decide to work on one task only, then in the commit message (git) mention to the task, when do we work on refactoring? how we name our commits?

edit:

as my question may be unclear (I'm sorry I'm not english native). We have tasks in team, and we are commiting to git with a task number. The first thing is: when to do refactoring? after sprint ends or in the middle? the second: how to name commits as we have convention to add task number in comment.

Improve this question
1
  • Your question is a little unclear. Are you asking about how to track refactoring as work within Scrum, or about something else? – Todd A. Jacobs♦ Feb 17 '14 at 22:00
10

The first thing is: when to do refactoring? after sprint ends or in the middle?

All the work needs to be done during the sprint, without exception. However, refactoring is not a task, it's a normal part of development, like stubbing, debugging or compiling. A task should be something concrete to achieve.

The second: how to name commits as we have convention to add task number in comment.

Since all the work is during the sprint and all the work is on user story, then use a link to the user story. Tasks are not very important in Scrum, stories are. Link to those, because it will make you remember "What was I trying to achieve here?"

Improve this answer
2
  • But when exctacly? During working on the task, before commit? – Filip Górny Feb 18 '14 at 8:39
  • 2
    @FilipGórny it is irrelevant whether you do a single commit or multiple -- they are still part of the same story. – Sklivvz Feb 18 '14 at 8:50
7

Refactoring - why and when

"Refactoring is risky. It requires changes to working code that can introduce subtle bugs. Refactoring, if not done properly, can set you back days, even weeks. And refactoring becomes riskier when practiced informally or ad hoc." - from a Foreword by Erich Gamma to Refactoring: Improving the Design of Existing Code by Martin Fowler et al.

First of all, I hope you have unit tests written for your code. "If you don't have unit tests, think long and hard before refactoring. Without tests, you can't know you didn't break anything. Write unit tests first if necessary."

I want my team to do refactoring as often as it is possible

"You don't decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing."

Now to answer your specific questions:

The first thing is: when to do refactoring? after sprint ends or in the middle?

Refactoring should be done during the sprint. As @Sklivvz pointed out, it is not a separate task. You do refactoring in order to accomplish a task for the story that you are working on.

the second: how to name commits as we have convention to add task number in comment.

Add the task number of whatever task you are trying to accomplish.

Improve this answer
1
  • 1
    Refactoring always as part of other tasks? Never planned? Typically this is something I would call "sounds good - doesn't work". In my experience planning some refactoring sometimes is just necessary. – Argeman Mar 9 '18 at 8:55
4

I suggest that you include refactoring within done defenation. As technical debit will grow and you need to pay it with interest. So just catogrize refactoring nessercy and include it within done defenation. Some refactoring is needed within the sprint and other within the release.

Improve this answer
1
  • Looks like this answer needs a little refactoring. defenation -> definition, debit -> debt, catogrize -> categorize, nessercy -> necessary. ;) – Richard Ayotte Jul 7 '19 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.