Introduction

Before I start introducing the tool I crafted, and more importantly, why I did so, let me tell you a little bit about my context.

These days, I’m primarily a full-stack web developer (mostly Ruby on Rails stuff), but I also do quite an amount of front-end work (mainly React). More often than not, I’m consulted for codebase reviews, refactorings, or pulled in on short notice to compensate short-term demand.

In all of these roles, I’ve come to realize that I need some tooling to get an overview of the codebase quickly, to address the pain points, and/or find out where the crucial logic of the software lies, to get to grips with it fast.

Now, let’s switch gears. Many authors (Michael Feathers, Sandi Metz, among others) have shown that an evaluation of churn (how often changes occur) vs. complexity of files in software projects provide a valuable metric towards code quality.

Churn/complexity charts are at the heart of many code quality evaluation tools, including CodeClimate, RubyCritic, es6-plato, and others.

You can read up on the science at the links I provided — I just want to concur with these authors, that surveying the files/classes with the highest churn * complexity product virtually always gives the best leads as to where to poke my nose in first.

So, when all these tools already exist, why build another one?

First, I don’t believe that just because an idea already has one materialization, no other variant of it should be built. By the same token — and that’s just speaking of the same domain — we’d only need one operating system, one programming language, one editor, one testing framework, etc. — you could continue this list endlessly.

No, open-source software as such has proven that a variety of tools to choose from is nearly always beneficial for the ecosystem. The community will have to decide whether I have built something valuable.

And second, as I already hinted at in the introduction, I’m not really satisfied with having to install — and learn — one tool for each of the languages I’m concerned with.

I’d rather have one single source of truth I can consult about code quality. So, I’ve set out to create a tool that serves mainly two purposes: