Has your codebase been feeling clunky lately? Riddled with superfluous conditionals? Is it harder and harder to add or change features?
Refactoring™ is the proven solution for re-organizing and simplifying code. Practitioners report improved readability and extensibility - all without any behavior changes to their program.
Ask your web professional if Refactoring™ is right for you.
Side-effects include higher levels developer happiness and velocity. Do not attempt Refactoring™ if your codebase is still in an exploratory phase.
Elm is fun to write but (especially for newcomers) it can quickly evolve into a giant tangled blob of code. Because we're confident the compiler has our back, it's easy to just keep piling code on top of code. Other times, the compiler keeps asking us to check cases you've already checked, leading to deeply nested redundant conditionals.
We often know that our code is messier than it should be but it's not always obvious how to untangle it.
I've helped many people clean up tangled Elm code and have started seeing some patterns. I have distilled these into 3 techniques:
- Write functions at a single level of abstraction
- Separate conditional code from doing code
- Push conditional logic up the decision tree
The talk will take a look at some common tangled code scenarios and discuss how applying these techniques.
In this talk, I'll be focusing on the following 3 techniques:
- Write functions at a single level of abstraction
- Separate conditional code from doing code
- Push conditional logic up the decision tree
We'll look at each of these in turn while walking through a series of refactorings starting with simple examples and working up to more complex problems. Examples will be a variety of commonly encountered scenarios including a few iterations of view code, some deeply nested cases/conditionals, and some awkward code that's been fighting the compiler.
The talk will briefly mention that improving data structures is a good refactoring technique but will not focus on that. Making better data structures has already been covered in many talks in the community so here I want to focus on the structure of functions instead.
The talk will also briefly discuss when not to refactor and what are some of the tradeoffs involved.
The goal is for attendees to have the tools to know what to do the next time they are confronted with some tangled code that feels insurmountable.