“You’re not a junior developer anymore: you’re here, at a conference…you have a right to change the code, and that includes its design.”
When Mark Menard stood up today at Windy City Rails to give his talk, “Let’s Do Some Upfront Design,” he examined the refactoring of code—including tests—and brought us to the realization that “All code is an impediment to change.” How do we stop that form happening?
We can use a series of tools and techniques:
- Sequence Diagrams: Get on a whiteboard and draw a picture.
- Collaboration Diagrams
- Mental Experiments: We can solve incredibly complex problems, using the right tools, with logical and creative thinking.
- Playing with Code/Exploratory Tests: After all, error messages aren’t dangerous.
And we can rely on a unitary, flexible rule of design to help us write more robust code and applications:
Practice separating what the code should do (coordinators) from how the code should do it (processors). This code is more readable, more testable, and more flexible.
But how to do that without churn?
- Identify a top level coordinator and give it a descriptive name based on use case.
- Write failing top level spec that runs everything without test doubles using real data.
- Write a failing coordinator spec using test doubles for the top level coordinator to pass the spec.
- Identify other coordinators, and repeat the process.
A favorite site of Menard’s for visualizing and designing code like this is websequencediagrams.com.
Mark thanks Justin Searls for his ideas, which influenced much of what he talked about today at Windy City Rails!
Find Mark at @mark_menard.