This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U71V6G2PDJS
At what scale would you consider adopting Big Rails patterns? For context, I’m working with a small team (4 engs) working on a Rails app that feels like it’s gotten too big for comfort. So we’re considering how to get the complexity under control.
I think the tipping point is where managing the current complexity is worse than the overhead of managing packs and dependencies… but maybe you could prepare by add documentation, measuring test coverage, etc. My hunch is that introducing packs will make things more complex in the short term.
Understanding the system is definitely an issue. And I would think accidental complexity introduced by what would probably be different packages reaching into the internals of eachother.
You’ll have that problem at the beginning anyway - it’s part of the process. If you have pretty clear dividing lines in the app between concerns, then breaking it up into packs could work with a small team if each engineer “owns” their domain and pretty much only works on that. Then you can each work not-in-isolation-but-at-least-one-directory.
The thing I like most about packs is that each one can have their own README, which makes it easier to know what’s in it (not that all of our packs have them, they don’t, but they should).
I’d sketch it out with the team - come up with a whiteboard drawing of your domains and some good guesses on their relative sizes. If the team feels that would make it easier to handle, then go for it. You might find you a single huge pack and a bunch of little “satellites” so it doesn’t actually make sense to break up since you still have to understand the huge on for the satellites to make sense.