Elixir Learning Objectives
Over the last week I’ve picked up a project I had sidelined for a while. Since I hadn’t looked at the code in while and I knew was part way into a particularly tricky pull request (changing the way a core structure is persisted to disk and read back) I looked around a bit.
I was surprised that the code did not feel in as good a shape as I thought I had left it. Worse, it wasn’t as good as I had set out to keep it. This is no client code, so there was no pressure to release any faster than I felt comfortable. Yet it was there, that nagging “Hmm.. This looks… odd”.
My hunch is that there are three lessons I still need spend thought-cycles on for Elixir:
- Smells and Refactoring: develop a better taste what good code looks like and what are safe operations to get there
- Data structures and modelling: I feel like I spend too much time shaping the data rather than coming up with a good structure once that I can leverage effectively. I probably still think too much Object-Oriented Design, too little Functional Programming. I also don’t have a good gage of when to use
- Size of modules and functions: My modules tend to get bloated. They are few in number and long in lines. My hunch is that I need to much more liberal with what gets extracted into its own module. This brings about a naming issue, that I also need to tackle.
As I come up with thoughts, ideas, approaches or articles that prove helpful in becoming better at these topics, I’ll share them here. Watch this space!