"That ticket touches the wizard code? Why don't YOU take that one". The wizard in question is so gnarly my colleagues are afraid to touch it.
Looking at the code through the lens of conditional cardinality reveals what went wrong and how we can make things better. This mental model will change the way you think about structuring logic and help you take your conditional code from scary to delightful.
This talk is aimed at an intermediate to advanced audience. While it will driven by a practical example (refactoring a multi-step form), it will mainly be about some more theoretical principles and mental models for structuring conditional code.
The big idea here is analyzing code from the perspective conditional cardinality (number of unique paths through a piece of code) and its implications.
Some of the main beats I plan to hit are:
- What is conditional cardinality?
- What happens when the cardinality of our code is greater than that of the underlying problem we are trying to solve?
- What makes this kind of code so hard to work with?
- A few different visual models of conditional code
- Contrasting the behavior of independent versus nested conditions
- Critically examining the idea of a "single linear path" when building logic
- Examining conditional cardinality across language paradigms
- Normalizing conditions to be syntax agnostic
- Identifying duplicated conditions, defensive coding, and "should never happen" scenarios
- Pushing conditional code up the decision tree
- Comparisons to type design and "making impossible states unrepresentable"
In order to stay grounded, the talk will be structured around refactoring a multi-step form (wizard) and how some common implementations accidentally cause a combinatorial explosion of paths and make the code almost impossible to read.
The main example will be in Ruby, but I will also show the same techniques at play with a similar problem in Elm. Both of these examples are inspired by real-world refactors I've done. In both cases the "before" code was so complex that my colleagues didn't dare make changes to it, yet afterwards they would do so confidently.
This will be a diagram-heavy presentation as I think many of the ideas are best shown visually.