The Case Against Monkey Patching, From a Rails Core Team Member

Monkey patching is considered one of the more powerful features of the Ruby programming language. However, by the end of this post I’m hoping to convince you that they should be used sparingly, if at all, because they are brittle, dangerous, and often unnecessary. I’ll also share tips on how to use them as safely as possible in the rare cases where you do need to monkey patch.

Eileen Uchitelle
15 min readadvanced
--
View Original

Overview

The article discusses the concept of monkey patching in Ruby, highlighting its dangers and advocating for its limited use. It emphasizes the potential issues monkey patching can cause, such as complicating upgrades, introducing security vulnerabilities, and increasing technical debt.

What You'll Learn

1

Why monkey patching can complicate upgrades in Ruby applications

2

How to identify and mitigate security risks associated with monkey patching

3

When to consider alternatives to monkey patching in your codebase

4

How to document and test monkey patches effectively if necessary

Prerequisites & Requirements

  • Understanding of Ruby programming and its frameworks

Key Questions Answered

What are the main dangers of monkey patching in Ruby?
Monkey patching can complicate upgrades, introduce security vulnerabilities, and increase technical debt. It can also change behavior in unexpected ways, making it difficult to maintain and secure applications. These issues arise because monkey patches affect global behavior, which can lead to unforeseen consequences.
What should developers do instead of monkey patching?
Developers should prioritize upgrading libraries, fixing issues upstream, and using inheritance where possible. They should also document any necessary monkey patches thoroughly, test them well, and have a plan for their eventual removal to avoid accumulating technical debt.
How can monkey patching affect application security?
Monkey patching can leave applications vulnerable to security issues if the patched code contains vulnerabilities that are not updated. If a developer forgets about a monkey patch, it may not receive necessary updates, exposing the application to risks even after upgrading to the latest version of the library.
What are refinements in Ruby and how do they compare to monkey patching?
Refinements allow for local modifications of classes in Ruby, providing a more contained way to alter behavior compared to monkey patching. However, they are still considered slow and can introduce similar issues, such as breaking in upgrades and causing security vulnerabilities.

Technologies & Tools

Some links below are affiliate links. We may earn a commission if you make a purchase.

Key Actionable Insights

1
Consider upgrading your libraries before resorting to monkey patching.
Often, bugs in frameworks are already fixed in newer versions. By prioritizing upgrades, you can avoid the complications that come with monkey patches and maintain a cleaner codebase.
2
Document any monkey patches thoroughly to ensure future maintainability.
Good documentation helps future developers understand the purpose and context of the patch, making it easier to manage and remove when necessary.
3
Always test monkey patches to ensure they work as intended.
Testing helps identify edge cases and ensures that the patch does not introduce new issues, providing a safety net when the patch is eventually removed.
4
Make a plan for the removal of any monkey patches you implement.
Having a clear plan helps prevent the 'write it and forget it' mentality, ensuring that patches do not linger in the codebase longer than necessary.

Common Pitfalls

1
Developers often forget about monkey patches after they are implemented.
This can lead to security vulnerabilities if the original code is updated but the patch is not. It's crucial to keep track of all patches and ensure they are revisited during upgrades.
2
Monkey patches can complicate the upgrade process for libraries.
When a monkey patch alters internal APIs, it may break during upgrades without any warning, making it difficult to maintain the application and leading to potential downtime.

Related Concepts

Open Source Contributions
Technical Debt Management
Code Maintainability Practices