Refactoring an existing codebase with functional error handling
Practice
As developers, we have a tendency to focus on what our code is supposed to do, the happy path. Unfortunately, the real world is rarely that simple. Our code fails: it fails frequently, in many different ways. Code that is simple when expressing the happy path very quickly becomes complex and cumbersome when expressing the reality of the situation.
One approach to this rising complexity which has proven attractive in functional languages is railway-oriented programming: a way of representing two parallel paths through the code, one for success and one for failure.
I'll be presenting a way to implement this, then running through some simple refactoring exercises to establish how to incrementally go from more conventional Java code to the railway-oriented approach.
Once you have this concept of railway-oriented programming, you start to see common patterns of failure that crop up time and again. I call these failure patterns, and taking a functional approach to Java makes it much easier to abstract over these, creating reusable solutions.
I'll talk through a couple of examples where I've built simple DSLs, then run through some more exercises to both use the existing DSL and also extend it where appropriate.
Familiarity with Java 8, and in particular lambdas/method references.
An understanding of how functional programming principles can be applied to better handle multiple code paths in Java.
A Github project with a series of incomplete exercises to work through, and cheat-sheets on the main constructs available in the library.
However, this is a coding session, so you'll need to provide a laptop set up for Java 8 (or higher) development.
Github repo can be found here: https://github.com/writeoncereadmany/spacontrolworkshop
Control library (subject of session) can be found here:
https://github.com/unruly/control
Slides (which, to be honest, aren't super helpful without commentary) can be found here: https://docs.google.com/presentation/d/1nRgl6S0I3_eICCCkNpOyWSTxHKAIBQai7MtbvxFNn54/edit?usp=sharing
I will write up a brief overview of the session to play along with at home and upload the quick reference sheets shortly.
The structure of the session is loosely:
Introduce an idea (slides, talking)
Apply the idea to a refactor on an existing codebase (this can be done solo, paired, or grouped, depending on how participants choose to organise)
Confirm understanding of the idea
Repeated a number of times, building up a more sophisticated and layered understanding of the approach.
3 iterations, each of:
10 minutes introducing idea (slides and talking)
10 minutes individual work (solo, pair, mob - however people like to form groups)
5 minutes presenting back and discussion
A before-and-after view of code applying different philosophies, a collection of repeatable katas to practice the railway-oriented approach, and a collaboratively developed understanding of what it is and how it works
I've presented the material as a BCS SPA talk, in June 2017, and the refactoring exercises as internal workshops at work.