Speakerline

Edit a proposal

Title Tags (comma-separated, max 3) Body

## Abstract

Rails has been around for (can you imagine!) about 15 years. Most Rails applications are no longer MVPs, but they grew from MVPs and usually contain a lot of legacy code that "just works."

And this legacy makes shipping new features harder and riskier: the new functionality have to co-exist with the code written years ago, and who knows what will blow up next?

I've been working on legacy codebases for the last few years, and I found turning legacy code into a _legendary code_ to be a very exciting and challenging process.

I want to share the ideas and techniques I apply to make legacy codebases _habitable_ and to prepare a breeding ground for the new features.

## Details

The _mechanics_ of this talk is based on a popular board game–[Terraforming Mars](https://boardgamegeek.com/boardgame/167791/terraforming-mars).

The goal of the game is to make Mars _habitable_.
The goal of the talk is to show how to make legacy codebases a better place to build new features.

The game flow inspires the narration.

#### Turn #1. Mars Landing

At the beginning of the game, we land on Mars to do some research work and plan future actions.

The best way to explore a legacy application is to make it up and running locally.
And this step is not that simple as it seems to be: the documentation/Readme could be outdated, external/system dependencies are tricky to install, configuration parameters are kept _secret_ (i.e., stored only inside someone's head).

During this step we create a Docker-based development environment: first, to simplify the _onboarding_ for future devs, secondly, to reveal the app configuration problems–making the codebase [12factor](https://12factor.net)-able reveals configuration coupling (=_hardcoding_) problems.

#### Turn #2. Covering Mars with ~~oceans~~ tests.

We have configured our development environment. Now let's try to run our tests (if any).

What do we want from our tests? We want them to be **reliable**.

We need minimal coverage: we should figure out the _golden path_ and make sure that it's covered at least with integration/system tests.

We need our tests not to be slow: we run tests more often in the early days when working on a new project, we don't want them to have a significant effect on our feedback loop.
Here I'd like to give a sneak preview (the topic worth its own talk) on how to analyze the test suite using specific profilers, apply some _patches_ to _heal_ the bottlenecks (e.g., getting rid of `database_cleaner` in favor of transactional tests).

We want our tests not to share global state (and thus be _flaky_). There are some typical cases of _global state_: database, uploaded files, test background jobs, cache, time traveling. I want to show how to detect and fix/prevent these problems with a little amount of code.

#### Turn #3. Planting of greenery.

Server is running, tests pass. We're ready to investigate the code itself.

We start with the dependencies:
- checking for known CVEs in dependencies
- checking for outdated patch/minor versions (no major upgrades)
- comparing local patches to upstream versions removing `github` dependencies from Gemfile when possible.

The goal of this _turn_ is to make our deps as up-to-date as possible without a lot of effort (so, minor breaking changes is OK). That would help us to do major upgrades in the future.

Let's raise the oxygen level and do some **code audit**!

Here I want to show how to detect security problems, performance issues (e.g., N+1), dangerous side-effects (like DB transactions atomicity violations or inconsistent DB state).

We also take a look at our configuration and make sure it's consistent (e.g., DB pool size vs. Sidekiq threads count).

#### Turn #4. Atmosphere.

Right before we started writing code, the last step we do is making sure that _atmosphere_ we've built is protected from _harm_.

We need to enforce _the new order_–we need ~~cops~~ "linters"!

Here I want to talk about how to add linters to the existing projects without rewriting everything (_progressive linting_), what tools we use to make development/review process automized.

Except form enforcing _rules_, we want to monitor the application health in general: we add instrumentation, collect metrics, configure dashboard and alerts. We don't need surprises.

#### End of Game. Life on Mars.

We made our app a good (enough) place to ~~live~~ code.

Here is the quick overview of what we did (_The Checklist_) – make sure you have all items checked in your app!

This talk is about, IMO, every developer should know to keep their application _healthy_; thus it fits anyone from newcomers to advanced Rubyists (though, I think, the latter know most of these techniques, it's would be good to refresh this knowledge).

## Pitch

I'm dealing with legacy code every day for the last three years. Every time I joined a new project (there were three of them during the period) I had to repeat almost the same actions (described in the talk). Why so?

Probably, due to Ruby and especially Rails _ability_ to build and ship things faster than any technology. We usually sacrifice quality for development speed. That's strategy is not that bad, I'd instead say "good." But it's easy to miss the point in time when you lose control of your code–your code becomes a _scary legacy monster_ 👻.

The goal of this talk is to demonstrate how to **keep legacy code under control**.

I don't want to talk about rewriting everything using _yet-another-hispter-artchitecture-design_ and be happy. It's great to know that there is a better world somewhere, but it doesn't help to solve your existing app problems.

This talk would be particularly useful for consultancy agencies and independent contractors/freelancers, who work mostly with legacy code.
And even if you just started working on a new Rails application, it's good to know how to keep it _habitable_.

My personal goal is to avoid repeating all the preparation the next time I start working on a new project because the project would have all the techniques I put in the talk applied.

Back to Speaker Directory