This came up a few days ago when I was talking with Steve and Nat.
We were holding a lunchtime retrospective about the latest delivery of our TDD course.
We talked about what had worked well, what we could do differently, and how we could customise the course for audiences with differing requirements.
Nat and Steve were keen to develop an exercise that would focus on refactoring. I liked the idea but I also wanted to keep an existing exercise which brings to life the value of intentional programming.
I felt that the ability to express intent was even more fundamental than the skill of refactoring.
It's risky to refactor unless you can check whether the code still does what is wanted. I don't think you can do that easily unless the tests and code express intention.
Nat reminded me that what you express, and how you express it, is different in code and tests. Good tests remind you of intent when they fail. This makes it easier to diagnose the cause of failure.
Refactoring is easiest with clean code, and clean code expresses clear intent. (Of course, as Steve pointed out, everything is easier if you have clean code).
You might refactor because the intent is not clear, but there are other reasons to do so. For example, you might refactor in order to make the code easier to change.
"The ability to pay back debt...depends on you writing code that is clean enough to be able to refactor as you come to understand your problem"Conclusion: we will develop a module on refactoring, but we'll keep our emphasis on writing clean code and tests that clearly express intent.
Ward Cunningham - Debt