Why, When and How to Do Ruby on Rails Code Review

A company got hacked. The hackers stole its customers’ sensitive data and demanded ransom, threatening to sell that data on the black market and let the story out.

The company’s website, built using Ruby on Rails, had a critical vulnerability: third-party libraries had been pasted into it alongside their source code. When one of those libraries was compromised, hackers used it as a loophole and got hold of the data.

Had the company audited its website code on a regular basis, this story wouldn’t have happened.

Ruby on Rails code review (or code audit) helps solve security and other problems. Read on to learn more.

What Problems Beyond Security Can Code Review Solve

Ruby on Rails code review can help identify security issues of an application, but that is not its main purpose. The main goal is to discover issues that slow an application down, making it expensive to maintain or difficult to keep developing.

We’ve been conducting code review and consulting for the past seven years. Our findings have ranged from grave vulnerabilities to inefficiencies that could be fixed in 2–3 hours, resulting in a 30% performance increase.

It’s as essential as regular health checks. Sometimes you might not be aware that you have a vitamin deficiency or hormone imbalance. But once you’ve found and fixed it, your mood surprisingly improves.

When to Audit Your Code

There are at least nine situations in which you might need to audit your code:

1. You are buying a technology business or planning to invest in one. A code review can reveal how much effort will be needed for that business to yield profits.
2. You are pitching your business to investors or buyers. Auditing your code can suggest improvements that you should make to your software before the presentation.
3. You are not well and truly sure that your application is secure.
4. Your application is slow and full of bugs.
5. The code in your application was written by different developers from scratch.
6. The last time you updated your software was more than a year ago.
7. You are having issues scaling your application, pairing it with third-party applications, or building new features.
8. You want to improve the performance of your app but don’t know where to start.
9. The development of your application seems too slow. That could be the result of technical debt and bugs — reviewing your code will help you sort out specific reasons. 

What Issues Can Ruby on Rails Code Audit Reveal

Slow and Buggy Application

The most frequent cause of poor performance that Ruby on Rails code audit can uncover are database issues such as incorrect structuring of data and N+1 queries.

Bugs in a Ruby on Rails application also affect performance, and bugs will always pop up. If you don’t take care of them, they will bog down your application. First of all, keep an eye on the gems that you are using. Once the Ruby community begins to gradually abandon a gem, it will accumulate ever more bugs with no one to fix them.

Inefficient templating languages are a common cause of slow Ruby on Rails applications. If you use one of those languages, replace it with a better rendering tool. Here is an example: if you are using HAML, replacing it with a HAMLit gem will improve your application’s performance.

Secondly, test as much of your code as you can. Fail to do that, and bugs will go unnoticed until their effect becomes apparent to your users, team and everyone else.

Overpaying for Resources

Many businesses, including companies using Ruby on Rails, often plan too far ahead when putting together the infrastructure of their applications. They use AWS servers that provide a higher capacity than necessary or third-party services that could be effectively replaced by cheaper alternatives.

As time flies, server load remains moderate, and expenses accrue, companies will waste thousands of dollars every year. Ruby on Rails code review can prevent or stop such inefficiencies.

If you find yourself in a similar situation, replace inadequate services, revisit your cloud server infrastructure and reconfigure your Ruby settings. 

You can continue operating under heavier traffic loads without making your Ruby on Rails application expensive. Ditch static infrastructure for a dynamic one that will automatically scale up and down with the load. You can do that using services like AWS Elastic Container and Kubernetes.

Difficulties with Further Development

As your business grows, you will need to scale your application, build new features and add developers. That’s when the effect of Ruby on Rails code review, or lack thereof, becomes evident.

The first issue code review brings to light is when the original code ignores Ruby community standards. When code is written without taking these standards into account, new Ruby on Rails developers spend days trying to understand it instead of pitching right in. Fix this issue by running the rubocop auto_correct feature. It will automatically adjust most code styles, and the rest is for you to change manually.

An outdated README file can cause you the same headache as non-standard code style. Just keep it fresh.

Another common cause of messy code is burying parts of your Ruby on Rails application’s logic in model callbacks. This makes developers skip callbacks and duplicate those parts of the logic. Clean model observers from those elements and adjust the application logic accordingly.

Inconsistencies in business logic can lead developers astray. Their actions may cause conflict between terms and conditions and how things actually roll, resulting in legal dispute and financial losses.

Finally, poorly organized front-end code at the startup stage can cause headaches with further development. We have seen applications where the entire code containing over 10,000 lines was presented in one file. With code like this, updating the application, adding features and removing bugs is virtually impossible.

Security Loopholes

That horrific story from the start of this article wouldn’t have occurred had the developers of that application installed third-party libraries using a package manager and monitored their updates.

Libraries aren’t the only source of Ruby on Rails security threats, though. Surprisingly many developers leave secret keys hard-coded in the main project repository. Once perpetrators get hold of the source code containing that data, they can access the company’s most sensitive information. This happens all the time.

Hence the advice: delete anything that doesn’t belong in your source code and its history of changes. If your access keys were placed in the source code at some point, change them immediately.

And don’t forget to cover as much of your code as possible with tests.

How We Review Code

We begin RoR code audit by studying the project documentation and product idea.

After that, we run the code through automated quality and security tests based on our own compliance checklist. This allows us to find out how the product stands against the best engineering practices and whether it has deprecated and outdated libraries.

At the next steps we look for issues in the database schema, back-end and front-end architecture, source code files and the project’s test suite.

Finally, we set the project up locally. This helps us understand what problems it may face at further development stages.

Sometimes we do additional checks such as compliance with the client requirement checklist, performance audit, advanced security audit, and review of the infrastructure and the integrated third-party software.

At the end, our client receives an RoR code review report — a comprehensive document featuring our findings and suggestions.

Conclusion

Code review of your Ruby on Rails application, done on a regular basis, can save you an unnecessary headache or two. And it can save you money, too.

You may be asking yourself: when exactly do I need to audit my code? If you have any concerns about your product and think that a code audit might help you resolve them, the answer is ‘now’. And we can do it for you — just drop us a line.