Kent Beck's Four Hats
Have you ever been coding and had a checkout which has gone out of control? The change involved a modification to a method, and adjusting the callers of the method too. It really got bad when some of the callers needed reworking, to cope with the new argument you added to the method. A colleague wanted a small part of the change, but you couldn't check-in because you would break the build. After a week you were done. Your reward was a difficult merge - the code base had moved on in the mean time.
Controlling the size of your checkout is a valuable coding skill. You should be able to take small, baby steps, and check-in at any time. There are a number of benefits. If you check-in frequently the merge to source control becomes trivial. Your colleagues won't get annoyed, because that change which they need is never far away. Most importantly you are in control of your work.
The trick to this control is to only wear one of Kent Beck's Four Hats:
| Interface | Implementation | |
|---|---|---|
| Refactor | Refactor code. Only change the interface. | Refactor code. Only change the implementation. |
| Add | Add new functionality. Only change the interface. | Add new functionality. Only change the implementation. |
Each time you switch hats, you run the tests. Each time you switch hats, you are in a position to check-in. In practice you may well switch hats quite rapidly, spending only a few minutes wearing each one. You don't have to check-in after each hat switch, it's just that you can if you want.
The worst out of control checkouts happen when you want to change the interface to an existing heavily used method, and you just steam in and do it. Along the way you are trying to do some refactoring as well. The out-of-controlness happens because your trying to change the interface and implementation at the same time. There is however a safe and incremental way to proceed:
- Copy the method you want to change.
- Change the interface to the new method.
- Adjust implementation of new method, unit test.
- Work though the code base adjusting the callers to use your new method.
- Delete the old method.
With this approach you can check-in at any stage in the re-work, without breaking the build.
When you are working you often see a bit of code which could do with a refactor. It's not part of the mainline task, should you interrupt and refactor? Go ahead, take 10 minutes and do it. Opportunistic refactoring improves the code base. But remember Coplien's Maxim Never interrupt an interruption
[Beck p. 41].