Over the years of working with large, mature, monolithical Rails applications, I realized a subtle problem. Many, even experienced teams put their con

Stop adding constants in the wrong place

submited by

Style Pass

2024-10-02 05:30:05

Over the years of working with large, mature, monolithical Rails applications, I realized a subtle problem. Many, even experienced teams put their constants in suboptimal namespaces. On one hand such placement is logical, but on the other it leads cluttered code that mixes low-level and high-level concepts. It does not help with keeping our monolith modularized either.

Consider a common scenario in a Rails application: the Team class. As your application evolves, you might find yourself adding constants like this:

Over time, you might even add convenience methods like Team.smb or User.smb_sales. However, as your company grows and adds more divisions, teams, and units, the Team class and team.rb file keep expanding. The core issue here is that the Team class itself doesn’t typically need to know about these specific team identifiers. It’s a low-level class that should remain generic and unaware of the higher-level domains built on top of it.

Do you know which classes/modules care about those constants? The ones that use them. Sales logic cares about the Sales team. Accounting logic cares about the accountants team. Contracting logic cares about the legal team.