As I explain software design through tidying I notice practitioners go through a consistent set of stages as they become comfortable making large changes in small, safe steps. I’ve put together the steps here to see how they do or don’t match your experience.
1. A Change is a Change
Programmers focused on changing the behavior of their programs just make changes. Some changes may also alter the structure of the program, but that pretty much happens at random.
With a bit more experience, programmers develop preferences for structures that make programming easier. Beyond creating those structures up front, though, they don’t have a notion of evolving the structure.
2. Refactoring
At this point someone hands them a copy of Martin Fowler’s Refactoring and their universe shifts. Hey, there are two kinds of changes — behavior changes and structure changes. Always be making one kind of change or the other, but never both at the same time.
(This lesson about never wearing two hats at once takes a while to learn and a few disasters to really sink in.)
3. Playing Chess
The next stage incorporates succession, the idea that you can profitably choose the sequence of behavior and structure changes. Some examples:
- Tidy first, making structure change so subsequent behavior changes become quicker/smaller/safer.
- Change behavior of messy code so the needed structure changes become clearer.
- Sort behavior changes into “now” and “later” depending on when they will pay off.
4. SB Diffs
In the last stage behavior and structure changes are sorted into separate diffs. Reviewers wear one hat at a time too. Behavior diffs are reviewed for correctness of behavior, freedom from unanticipated side effects, and coverage of tests. Structure diffs are reviewed for desired eventual structure and contribution of the diff in the direction of that structure.
