7 Ruby Gems That Catch Code Quality, Security, and Performance Issues Before They Ship

I remember the first time I pushed code to a Rails project that was already running in production. I had checked the logic twice, run the tests, and felt proud. Then my senior developer sent me a pull request review with a dozen comments about style, security, and complexity. I did not know where to start. That moment taught me that writing code is only half the work. Keeping it clean, safe, and consistent is the part that saves you from embarrassment at three in the morning when the site goes down.

Over time I collected a set of tools that catch mistakes before they reach your teammates. These seven gems do the heavy lifting so you can focus on features. They integrate with your development workflow and your continuous integration pipeline. You do not need to remember every rule. The tools remind you. Let me walk you through each one, with examples drawn from real Rails projects.

---

RuboCop

I put RuboCop first because it is the one I reach for first on any new project. It enforces the Ruby style guide and flags Rails‑specific patterns. You add three lines to your Gemfile:

gem 'rubocop', require: false
gem 'rubocop-rails', require: false
gem 'rubocop-rspec', require: false

The require: false is important. You do not want these gems loaded at runtime. They are only for analysis.

After running bundle install, create a .rubocop.yml file in the root of your project. Start with something simple:

inherit_from: .rubocop_todo.yml

AllCops:
  NewCops: enable
  TargetRubyVersion: 3.2

Rails:
  Enabled: true

Then run rubocop --auto-gen-config to generate a .rubocop_todo.yml that excludes current violations. You can slowly fix them one by one.

What does RuboCop catch? Let me show you a typical example. I once wrote a controller action like this:

class PostsController < ApplicationController
  def create
    @post = Post.new(post_params)
    if @post.save
      redirect_to @post, notice: 'Post created.'
    else
      render :new
    end
  end
end

RuboCop flagged a few things. First, the method was longer than ten lines. Second, I used redirect_to @post without checking if the record had an id. Third, I used string interpolation inside the second argument of redirect_to – RuboCop prefers parentheses around method arguments for clarity.

After running rubocop -A (auto‑correct), my method became:

class PostsController < ApplicationController
  def create
    @post = Post.new(post_params)
    if @post.save
      redirect_to(@post, notice: "Post created.")
    else
      render(:new)
    end
  end
end

Small changes. But when you have a hundred controllers, these small changes keep the codebase consistent. Any new developer can look at your code and know where to put the parentheses.

The rubocop-rails extension adds cops for SQL queries (enforce where.not instead of where(attribute: nil)), routes (enforce member/collection blocks), and time comparisons (use Time.zone.today instead of Date.today). It makes your Rails code follow the community standards.

I run RuboCop before every commit. I have a Git hook that prevents committing if the code has style violations. It saves me from adding extra commits later.

---

Reek

RuboCop handles style. Reek handles design. It looks for code smells – patterns that indicate deeper problems. Things like duplicated code, long parameter lists, or a method that knows too much about another object.

Add it to your Gemfile:

gem 'reek', require: false

Run reek app/ and it prints a list of smells. Let me give you a concrete example. I once had a service object that looked like this:

class OrderCreator
  def initialize(user, product, quantity, discount_code, shipping_address)
    @user = user
    @product = product
    @quantity = quantity
    @discount_code = discount_code
    @shipping_address = shipping_address
  end

  def call
    # 20 lines of logic
  end
end

Reek reported “Too Many Parameters” for the constructor. Five parameters is a lot. It also reported “Feature Envy” because inside call I kept calling methods on @user and @product as if they were local. The solution was to group related data into a single object – a value object or a command object.

class OrderCreator
  def initialize(order_params)
    @order_params = order_params
  end

  def call
    @order_params.user.orders.create!(
      product: @order_params.product,
      quantity: @order_params.quantity,
      discount_code: @order_params.discount_code,
      shipping_address: @order_params.shipping_address
    )
  end
end

Now the constructor takes one parameter. The method no longer envies other objects because it delegates.

Reek also catches “Duplicate Method Call” when you repeat the same computation, and “Nil Check” when you guard against nil too many times. It forces you to think about design patterns like Null Object or Presenter.

I run Reek once a week on the entire codebase. It slowly guides me toward better abstractions.

---

Brakeman

Security is easy to ignore when you are under a deadline. Brakeman makes it hard to ignore. It statically analyzes your Rails application for vulnerabilities without running the code.

Add:

gem 'brakeman', require: false

Run brakeman -o report.html and open the generated HTML file. It lists every potential issue with a risk level – High, Medium, Weak.

One common warning is SQL injection in where clauses. I once wrote:

User.where("email = '#{params[:email]}'")

Brakeman flagged it as High. The fix is to use parameterized queries:

User.where(email: params[:email])

Another warning is cross‑site scripting (XSS) when you use html_safe or raw. I had a helper that returned "<b>#{user.name}</b>".html_safe. Brakeman pointed out that if user.name contained JavaScript, it would execute. I switched to content_tag(:b, user.name).

Brakeman also checks for mass assignment vulnerabilities, unsafe redirects, and dynamic render paths. I run it before every deploy to staging. If it finds a High issue, the deploy stops. It has saved me from shipping bugs that would have leaked user data.

---

Fasterer

Performance is not always obvious. Fasterer finds patterns that are slower than alternatives. It comes with benchmark data to prove the suggestions.

gem 'fasterer', require: false

Run fasterer path/to/file.rb and it shows something like:

Using `gsub` instead of `tr` is slower
Calling `keys` on a hash is slower than `each_key`
Using `map` followed by `flatten` is slower than `flat_map`

I had a piece of code that cleaned user input:

input.gsub!(/\s+/, ' ')

Fasterer suggested tr because it only handles single‑character replacements. But my pattern was multi‑character. So I dismissed that one. But the map.flatten warning was valid. I had:

users.map { |u| u.addresses }.flatten

Fasterer recommended:

users.flat_map { |u| u.addresses }

It saves a method call and creates one array instead of two.

Another common suggestion is to use Array#bsearch instead of find when the array is sorted. I never think about that. Fasterer does.

I run fasterer on the parts of the codebase that handle heavy data processing – like reporting or batch jobs. It gives me small wins that add up over thousands of requests.

---

SimpleCov

You trust your tests. You also trust that they cover every line. SimpleCov shows you which lines are never executed.

gem 'simplecov', require: false

In spec_helper.rb or test_helper.rb, put this at the very top:

require 'simplecov'
SimpleCov.start 'rails'

Now when you run your test suite, it generates a coverage/index.html. Open it in a browser. Green lines are covered. Red lines are uncovered. You see exactly what you missed.

I use it with a minimum threshold. In spec_helper.rb:

SimpleCov.minimum_coverage 90

If coverage drops below 90%, the test suite fails. I started with 70% and slowly raised the bar. It forced me to write tests for edge cases I would have ignored.

One personal example: I had a before_action in a controller that set a variable. I never wrote a test for that controller because I assumed the variable was set by a parent class. SimpleCov showed red. I added a simple test. Later, someone refactored the parent class and broke the variable. My test caught it.

SimpleCov also works with parallel tests and can merge coverage reports from CI. I set it up so that every pull request shows a coverage badge. If the badge turns red, we know something was left out.

---

Rack::MiniProfiler

This gem is different. It does not analyze code statically. It shows you performance data on every page in development.

gem 'rack-mini-profiler'

Add it to your Gemfile. No configuration needed. Open any page in your browser and look at the top left corner. A small badge appears. Click it and you see a timeline of SQL queries, view render times, and memory allocations.

It helped me find an N+1 query once. I was loading posts and then iterating over each post to show the author name. The profiler showed 50 SQL queries for a page with 50 posts. I added includes(:author) and the queries dropped to two.

You can also use MemoryProfiler for heap allocation details. I used it to find that a helper was creating a large hash on every request. I cached it with ||= and the page load time dropped by half.

In production, you can enable it for authenticated users only. I have it on staging with a header parameter. That way I can check performance before releasing.

---

flog

Flog measures code complexity. It counts the number of paths through a method and the number of assignments. A score above 20 per method suggests you should refactor.

gem 'flog', require: false

Run flog app/ and it lists every method with its score. The highest ones are the most complex. I once had a show action that handled seven different states. Flog gave it a 45. I extracted each state into a separate method, and the main action dropped to 8.

Here is an example. Suppose you have:

def calculate_discount(user, item, promo_code)
  if user.vip? && item.in_stock?
    if promo_code == 'SAVE10'
      item.price * 0.9
    elsif promo_code == 'SAVE20'
      item.price * 0.8
    else
      item.price
    end
  else
    item.price
  end
end

Flog gives this a high score because of the nested conditionals. I can simplify by using a hash:

DISCOUNTS = { 'SAVE10' => 0.9, 'SAVE20' => 0.8 }.freeze

def calculate_discount(user, item, promo_code)
  return item.price unless user.vip? && item.in_stock?

  multiplier = DISCOUNTS[promo_code] || 1
  item.price * multiplier
end

Flog now gives a low score. The method is easy to read and test.

I use flog to find methods that need attention during code reviews. If someone submits a pull request with a flog score above 20, I ask them to split it.

---

Putting It All Together

You do not need to install all seven at once. Start with RuboCop and SimpleCov. They give you the biggest return for the least effort. Once your code is consistently styled and well covered, add Reek to improve design and Brakeman to lock down security.

I run these gems in a CI pipeline. A typical script in my repository looks like this:

test:
  script:
    - bundle exec rubocop
    - bundle exec brakeman --quiet
    - bundle exec reek app/
    - bundle exec flog app/ | tail -5
    - bundle exec rspec

If any step fails, the pipeline stops. No one merges code that breaks quality.

The gems also work together. Brakeman will flag SQL injection, but RuboCop might flag the same line for style. SimpleCov will tell you if the line is tested. Flog will tell you if the method is too complex. You get a full picture.

I have been using these tools for three years now. They caught hundreds of issues before they became bugs. More importantly, they taught me to write better code by example. Every time I run them, I learn something – a new pattern, a faster method, a safer query.

Start small. Add one gem today. Run it on your current project. Fix the first few warnings. Then add another. Over time, your codebase becomes something you are proud to share. And when the site stays up through the night, you will know the tools helped.