I'm not a great programmer; I'm just a good programmer with great habits.1
The first time I read this, was a galvanizing moment in my programming career. A relief by understanding that we're not supposed to be perfect and there's absolutely no way that you can spot every single problem at any determinate time in a codebase, that is up to you to set the processes, tools, metrics in place to ensure that you're delivering adequate, good quality software.
Over the course of the years, I've found, as has the Ruby community created and standarized upon, tools that aid the development, ensure code quality, visualize performance, etc. While they're not a replacement to programming experience, and above all, common sense, they're essential to any developer workflow that takes the above quote into consideration, so I've decided to put a quick list here as a note to self and maybe to others that might find it useful.
The absolute essentials
An absolute (paid) essential: CodeClimate
If you don't mind paying (unless your project is open source), CodeClimate is an absolute essential for measuring code quality, as they put it: it's automated code review for your projects (but doesn't exonerate you from actually doing code review), and it even includes coverage and security audits, last time I checked.
Now, while I consider this essential, this shouldn't be your one and only point of measure, and you can go as far as skip it.
An absolute essential: rubocop
If you take anything from this post, add rubocop to your
Gemfile, period. It's a "Ruby static code analyzer, based on the community Ruby style guide." In case you didn't know we had a style guide, you can check the Ruby style guide, as well as the Rails style guide, both of them compiled by the author based on the community input. If you did, I'd recommend check it again, you'll be doing someone a favor ;).
Rubocop is an absolute essential for any Ruby project, is highly configurable (although I'd recommend to stick to the default settings, they're the default for a reason), and it helps set a code standard for your team, enforced/hinted by tools. You can go as far as to make a build fail if the style isn't complied with entirely, or you can use it as part of your pre-push hook, or run it from time to time, the choice is up to you. There are also several plugins, such as the one for RSpec, and also editor integration.
An absolute essential: rails_best_practices
The rails_best_practices gem and the companion website are one of the best things that has happened to the Rails community. If you're doing Rails development, which most of us Ruby devs are, this is another essential tool that needs to be on your toolbox. It's a metric tool tailored specifically for Rails projects, it was mentioned on this Railscast and this episode of Ruby5 as they point out in the project's README.
If you're using an IDE
A quick aside: if you're using and IDE they might be some form of code quality checking built-in, I know Rubymine/IntelliJ have a pretty comprehensive one you might want to check as well.
While they might not be essentials, I by no means intend to give the impression that they're either not necessary or of lesser quality, they certainly provide more analysis tools and metrics, metrics, metrics.
- reek: Detects code smells
- flog: Analyzes code complexity.
- flay: Detects code duplication and structural similarity.
- bracketman: Static security analyzer for Rails apps.
- bullet: Detects
- cane: Will fail your build if quality thresholds are not met.
- metric_fu: It used to be kind of old, props if you get it to run, an aggregator for many of the tools we've mentioned and more.
Leveraging these tools and integrating them into your process will inevitably result in an improved code quality because of the warnings they report and the instant call-to-action for everyone and anyone in your team. I hope it has been useful to you, I know I'll be coming back to this post for every new project I setup, and let me know via comments if you have any suggestions.
Kent Beck in: Martin Fowler, Kent Beck, John Brant (2012) Refactoring: Improving the Design of Existing Code. ↩