Refactor Mercilessly, or not
XP tells us to refactor mercilessly. In some ways this is totally true, in others it leads to difficulties for real live teams.
For clarity, refactoring should be done mercilessly. If you can't understand the code immediately, it is a no brainer. It is of no use to anyone using it.
For encapsulation, refactoring should be done mercilessly. This will save your bacon, when you defer the refactorings below.
For duplication, you should refactor almost all the time. Duplicate code creates multiple points of potential failure and hence harder debugging. However sometimes, duplication is hard to spot. Code does the same function, but doesn't look the same. Other people haven't noticed the similarity. Sometimes it is hard to remove the duplication, because the responsibilities are slightly wrong and the duplicate code is dispersed.
For redesign, you need to refactor when the code can converge. Sometimes you just don't know enough about the behaviour of the code to redesign by refactoring. In this case you must wait until there is enough "convergence" in the code. I call convergence the point where the code starts screaming at you what the objects are and how to put them together.
0 Comments:
Post a Comment
<< Home