Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto G

May 26th, 2009 at 10:48 am

Refactoring: The 5 main questions: Why? When? What? How? Who?

with 4 comments

Why?

There are two main reasons to refactor.

  1. To improve the code/design before building on it’s top: It’s really hard to come up with good code on the first attempt. The first try to implement any initial design will show us that we misinterpreted or forgot some logic.
  2. To adapt to changes in the requirements. Change happens in the software development; to be responsive to change is better to have a good code base.

We have two options for both scenarios, path the code or refactor it. Patching the code will lead us to unmaintainable code, and will increase our technical debt, it’s always better to refactor.

When?

The sooner the better as is easier, faster and less risky to refactor over a recently refactored code rather than waiting to refactor for the code to be almost completed.

What?

All the code and all the design are candidates for refactoring. An exception for not refactoring something could be a working piece of code which is quality is low, but due to be close to a deadline, we prefer to keep our technical debt rather than risking the planification.

How?

There are two rules to never be broken when refactoring

  1. With lots of unit tests. This is going to give confidence to the developer that he is not breaking anything during the refactor.
  2. With consistency. There’s many ways to improve the code, but the underlying direction has to be always the same, for example: if you are always using error codes and not exceptions, keep using error codes… This will make sure that everyone is rowing in the same direction

Who?

Two persons should be in charge of the refactor.

  1. The developer who created the code. He will have the main role of the refactoring, he will perform all the changes.
  2. A senior developer. To supervise the refactoring, he will mainly keep an eye on consistency.

So, is refactoring good or is it bad?

Refactoring is the essence behind iterative development, but in order to turn it into a good practice you have to be very careful, again, it’s essential to have unit tests, and to refactor with consistency, if you do so refactoring will turn into a very powerful tool for your team.

External references.

The main reference about refactoring is the book “Refactoring: Improving the Design of Existing Code” by Martin Fowler, a must read for any software developer. Other references are:

4 Responses to 'Refactoring: The 5 main questions: Why? When? What? How? Who?'

Subscribe to comments with RSS or TrackBack to 'Refactoring: The 5 main questions: Why? When? What? How? Who?'.

  1. […] Alberto Gutierrez has posted a good article on refactoring titled Refactoring: The 5 main questions: Why? When? What? How? Who? […]

  2. […] order to keep up to date with good code that matches the new/changing requirements is essential to refactor the code as we go. As this is a risky task there are 2 main preconditions to avoid entering new bugs into the […]

  3. […] order to keep up to date with good code that matches the new/changing requirements is essential to refactor the code as we go. As this is a risky task there are 2 main preconditions to avoid entering new bugs into the […]

  4. […] Refactoring: The 5 main questions: Why? When? What? How? Who? | Making Good Software (tags: refactoring code development) […]

Leave a Reply