Using Lines of Code (LoC) for measuring developer productivity is a well known poor metric; roughly equivalent to measuring success in building aeroplanes by weight of the planes produced.
However looking into LoC in a code base can be a powerful proxy for technical debt issues and issues of complexity when considering a single file, class, module or a function.
Long functions or methods typically violate good coding practices by exhibiting the following issues
My post about performing recurring or periodic tasks in Elixir using receive timeouts and Tasks couple of weeks ago sparked quite a few conversations which was amazing! Thank you to everyone here on Medium, Twitter and in Reddit for sharing your experiences and suggesting alternatives.
Two of the things that came up most was using
Process.send_after and concerns about drift caused by execution of the work. We’ll look at both of these in this post.
If you haven’t checked out the first post yet you can find it here: Periodic tasks with Elixir
As soon as I had posted the…
Like many working in a legacy Ruby system and learning Elixir we were struggling to figure out how to start moving our code over. Here I wanted to share a technique we used a year ago to start the process.
At Fitzdares (a bookmakers) we have an ageing monolith of a system written in Rails over 7 or so years by various teams and contractors and much like the building above it’s starting to show it’s age and as is the case with many monoliths the responsibilities of the system started to include everything imaginable.
We decided we would focus…
I’d argue that most projects I’ve worked on over the years all have eventually included a periodic task of some sorts; daily reminder email, overnight processing task, polling an API that doesn’t provide a web hook etc.
With Ruby the answer was always a cron job that would invoke a rake task. This had couple of problems with it, first I could never remember the crontab format. Second was where to place the configuration and how to make sure it was up to date.
Gems like Whenever would help fix many of my grievances but with Elixir there’s in my…
In the previous part we looked at how to refactor away conditionals in the middle of your functions by passing in a function instead. Before that we looked at refactoring away conditionals at the beginning and end of your functions.
If you’ve not read through the series yet I recommend you start from the beginning
In this post we will look at a way to deal with nested conditionals. …
In the last part we looked at a technique for refactoring away conditionals at the end of your functions and before that we looked at using pattern matching to eliminate conditionals from the top of your functions.
If you’ve not checked them out yet I recommend you do
In this post we’ll be looking at how we can clean up some code where two or more functions need to have the same start and end but something slightly different in the middle.
Last time we looked at using pattern matching instead of starting our functions with conditionals. If you haven’t checked it out yet you can find it here: Quick & Easy Elixir Refactorings — Part 1
This time we’ll look at a super simple technique you can use to remove the conditional from the end of your functions by extracting a function and next time we’ll deal with conditionals in the middle of your function.
All of these techniques by themselves may seem hardly worth it and not making a big difference but stay with me; I’m hoping in couple of…
Over the next few blog posts I’ll be covering some quick easy refactorings that could help you tidy up your Elixir codebase.
We’ll go over some patterns you might find in your code and look at simple techniques you can use to hopefully make your code neater, easier to work with in the future and more readable.
In this first post I’ll cover functions that start with a conditional. In following posts we’ll cover functions that start with similar code but with different ends and functions that have something slightly different in the middle among others.
This is a pattern…
I have three main reasons why I ask about patterns and why I think you should too.
This is the obvious one. Lot of smart people spent a lot of time coming up with great ways to solve many of the problems you are likely to run into whilst you’re refactoring problematic code or building out new features.
Patterns often get a bad rap as it’s…
In case you’ve not heard the term before lightning talks are short presentations — literally fast transfers of information.
I started lightning talks at my previous couple of companies and they quickly became my most successful initiatives gaining rave support from everyone from owner/founders to temporary summer interns.
Here’s some notes to help you introduce lightning talks at your company including why I think they’re great, rules I’ve found useful and other things I’ve learned running them.
Lightning talks are simply short concise presentations usually given by a single presenter on a topic of their choosing to a voluntary audience.
Freelance Developer • Founder of @CodeHalf • Rubyist • Elixir Alchemist • Wannabe Data Scientist • Dad