gistfile1.txt

Conference: RailsConf 2022
Status: Rejected

# Title: Escaping The Tar Pit (The Mythical Service Layer) 

# Abstract: 

Nobody wants to inherit a project that reeks but here we are: Stuck in the tar pit. Fat models? Endless service classes? How can we take control of all the tech debt? 

In this talk you will learn how to use a few, great Ruby gems that will guide you out of that sticky tar you are in. On top of that, you will learn a repeatable way to gradually pay off technical debt.

# For Review Committee -- Details: 

I will start by talking about different types of technical debt (not just related to code!) and then I'll focus on how we got here:

* Test Coverage: How well covered is my service layer?
* Cyclomatic Complexity: How complex are the methods in my service classes?
* Code Smells: Are there any known code smells in my application?
* Churn: Which are the files that keep changing over and over again?

I will explain that the mythical service layer could be hidden in your models or simply within `app/services`

## Test Coverage

I will talk about SimpleCov and how we would use it to calculate test coverage for our service layer. Usually the most complex files are the ones that are hardest to cover with our test suite. 

## Complexity

I will talk about flog and how we would use it to calculate a score for our application. Combined with the previous section, we will be able to calculate the relative cyclomatic complexity (super complex methods are so much worse with 0% test coverage)

## Code Smells

I will talk about reek and how we would use it to find code smells in a sample Rails application.

After going over these three sections, I will talk about a new tool that I've built to take all these things into account and calculate your service layer's maintainability score. Let's call it the Skunk Score :)

Finally I will talk about how you can use this one metric to gradually improve your application by reducing technical debt every week

# Pitch

Ruby was invented with programmer's happiness in mind. That's why I love the language, but I've found so many projects that have led me to have my doubts about it.

It is so hard to judge code quality before you take on a project. Most of the time you have zero visibility before you accept a job offer. Wouldn't it be great if you could ask the company: What's the Skunk Score of the application I'll be maintaining? Could I see a report generated by Ruby Critic? 

The tools that have been published in the Ruby community are great, but there is not one single metric that we can use to judge the quality of our applications. This talk is an attempt to start a conversation around this topic: Wouldn't it be wonderful if we had one, open source, easily configurable algorithm to judge code quality?

I know that there are many commercial tools out there (e.g. Code Climate) and I really like them, but this talk is not about them. It's about the tools that are already available and how we can use them to make our lives even happier!

The mythical service layer is sometimes a fancy way of saying "fat models" which can become a huge layer of very complicated code. You can use Ruby gems like `skunk` and `ruby-critic` to find a common language for your team. 

As the maintainer of these two gems, I believe I can share my experience using them in real life Rails applications with a lot of technical debt.

Attendees will leave this talk knowing a few concepts and tools they can use to describe and improve the technical debt in their service classes.

# Bio

Ernesto is the Founder of FastRuby.io, a productized Rails upgrade service dedicated to paying off technical debt and upgrading your dependencies. When he is not playing chess, he likes to maintain a few Ruby gems including ruby-critic, skunk and next_rails. He is passionate about writing less code, launching minimal products, coaching entrepreneurs, contributing to open source, and eating empanadas.