12 Helpful Rules for Refactoring a System

Name: 12 Helpful Rules for Refactoring a System
Type: Rules
Status: final
Version: 2008-04-25

Gist: to provoke 2nd thoughts if you are to take some part in a refactoring. Refactorings seem to come about more frequently these days, maybe because even the stolid of the business people start to talk about 'agile'. Like all these now-buzzwords, there's a lot of potential misunderstanding hiding in the very word.

Refactoring DEFINED AS modifying something without changing its externally observable behaviour with the purpose of making maintenance easier. Note that you can refactor many things, ranging from systems to architectures to design to code. However, relevant literature suggests that Refactoring is meant to relate to Design and Implementation. See Martin Fowler's Website. Also see Code Refactoring.

R1) Whenever you hear the word refactoring, run! 'just joking...

R2) Precisely understand what the various stakeholders think a refactoring is. You'll be surprised. Correct the wording if needed.

R3) Precisely understand what purpose the refactoring has, from each of the stakeholder's point of view. Align expectations before you start.

R4) Assume a great deal of resistance from the people who pay. Refactoring for them is another word for "Give me $$$, I'll give you what you already have! " Find out who will pay for maintenance.

R5) By all means reduce the risk of having a system with new bugs after the refactoring. This can be done by rigorous test driven or even behaviour driven development for example. Any change in behaviour should be treated as a bug.

R6) Challenge the business case (if any ...) of the refactoring. At least, do proper cost-benefit analysis. For example, the system may not live long enough to amortize refactoring.

R7) Prepare for the situation that nobody can provide exact and dependable information on how future budgets will be affected by the refactoring

R8) Back off from refactoring if significant portions of the code will be both refactored and worked over due to new requirements. Do one thing at a time and bear in mind R5.

R9) Prepare for 3 different points of view if you ask 2 people for what specific refactorings should be done.

R10) Think of short-term and long-term effects.

R11) The improvement must be both quantified beforehand and measured afterwards, at least for non-local changes to the system.

R12) Be suspicious if someone suggests only one or two specific refactoring techniques will suffice to reach a project-level goal.