Use a refactoring checklist to pay down Technical Debt as you work
Posted by Marcus Wyatt on 13 August 2005
The triumvirite TDD coding cycle of “Red, Green, Refactor” is plastered all over the web and endlessly repeated by all us TDD zombies. If you’re going to drink at the agile Koolaid fountain, don’t stop with just “Red Bar, Green Bar.” You’ve got to do the third part and Refactor as you work to keep the code clean.
- Can you easily add more code to the solution tomorrow?
- Is your code becoming difficult to read and understand?
- Are you spending too much time with your debugger?
- Is there a class or namespace you avoid changing out of fear?
You will slow down if you let problems accumulate. If you’re using evolutionary or incremental design you probably don’t know exactly where you’re going with your design. You are purposely delaying design decisions until you have more information and knowledge about the design needs. Keeping the code clean and each class cohesive with low coupling will maximize your ability to change later. Constant vigilence and an adherence to good coding practice can extend the lifecycle of a system by reducing the risk and cost of change.
Use aggressive refactoring to keep the technical debt from building up. Integrate refactoring into your normal working rhythm, don’t let it just build up into day long tasks. Here’s the good news though — a lot of refactoring work is quick and easy, especially if you’ll invest some time in learning the automatic refactorings in tools like ReSharper.
Find the whole post and comments here.
tags: code-smells, coding-practices, refactoring, tdd
Currently listening to: mp *** 470. umek – expire ep (b2)