What to do when your code is starting to smell

When I started as a Cabify Engineer, Cabify was growing exceptionally quickly. This is quite common in a large start-up, but for me it was a real challenge as I didn’t have the experience to deal with some of the problems it brought.

The amount of data was growing rapidly, so our CouchDB database needed some load taken off to improve its performance. Our first solution was to use ElasticSearch, one of the best databases for querying full-text documents.

ElasticSearch complements CouchDB extremely well because one of Couch DB’s limitations is that for all queries you have to either know the document ID, use map/reduce, or have an index.

Because it’s widely used, lots of people have written and published integrations for ElasticSearch, with the result that you end up with different gems to solve your problem that are all almost the same, but not quite. And as everybody knows, new solutions create new problems, or in this case, can aggravate existing ones. So, we were not sure which gem to choose.

Finally, we settled on Chewy.

Why Chewy?

Our rails models in that moment were quite clumsy and ugly. Quite frankly, our Code smelt. It often happens when your priority is not optimised and you only want to scale the product. So yes, this was a good moment to think about our future as code cookers.

We wanted to separate our searching logic from our models. It’s not a really business problem how a model gets the info, so adding this logic to our models and mixing it with business logic meant adding more… well, bad smells. Another problem we’d hoped to avoid would now be getting bigger.

I’d like to show you a short example for how simple it is to use Chewy after installing the gem. For example, you can create a new index in a few easy, intuitive steps:

Step 1 — Add the updater to your model like this:

Step 2 — Then create your new index:

Step 3 — And finally make a method for querying the data:

As you can imagine, it’s harder to make more complex queries and indexes, but in essence Chewy tries to make a new job simple and easy to understand. In only 3 steps you have a new Index for searching your data, avoiding heavy querying to CouchDB.

Working with Chewy has taught me the benefits of keeping things simple and well-structured. When I need to create some new index or query, I can quickly look for the folders without having to re-check the documentation (crucial when you have a memory as bad as mine!) and get back to using this new search engineering.

Conclusion

Thanks to this solution for the initial issue — reducing the load in CouchDB — we now get the data from a different datasource (ElasticSearch) for our less important queries. And, perhaps most satisfyingly, we managed to avoid creating a new problem or inflaming the one we already had.

I guess it’s made me realise that it’s not enough just to improve your own performance, you also need to be conscious of your work environment and understand how your future workmates are going to read and rewrite this code. Making code that is simple to understand, find and pull apart is hard work. But that’s coding, and if it was easy, it probably wouldn’t be as much fun.