Preface: This is not much about how to structure code within files. I have that down. This is more of the topic of organization of your source tree. Hopefully someone will just say, “Here’s a great link on the topic.” However, firsthand opinions on the subject are welcome too.
So I’ve done a bit of digging on this subject and find tons of material on simple structure. I guess the assumption is that, by the time you need to deal with the problems of the size of your codebase, you’ll already know the answer. However, even the IDEs seem to be waging a holy war on how these projects should be structured (which is NOT what I wanted to start in this thread).
Java enforced the package structure in the language. Kudos for that. Eclipse then lets you use projects to have (potentially) independent — we’ll call them ‘buckets’ in this example — buckets of related code. Intellij has distinct but similar concepts with ‘modules’ within a singleton instance of a ‘project’. If you want another project, you’re essentially starting from scratch.
However, RubyMine offers no such modules in ruby apps, and by default just wants to slam everything into the root directory. It allows Directories, so one could essentially just pick some arbitrary tree structure and run with it. This implies to me their intent was that all classes have access to all other classes within your project. This might have some resolution through the use of Ruby ‘modules’, or might just be an honor-system pattern of “don’t reference that stuff.”
So, to put it succinctly, say I were building a ‘foo’ and a ‘bar’ concept, and both depend on a ‘util’ class. maybe I’ll deploy them as gems, maybe I won’t. I could:
- Slam them all into one RubyMine project and just ignore the fact that ‘foo’ and ‘bar’ have no reason to be aware of each other.
- Put each in its own RubyMine project. This seems like a real pain if there is any concurrent development. First of all, ‘util’ would have to be packaged separately and then included as an external resource in the other projects.
Neither seems particularly appealing. Thougts?
I’d develop all three independently, then make util a gem. In the Gemfile for each of foo and bar, you can give a path to the gem so that you can develop them all concurrently without the pain of messing with version numbers and so forth (for production, you would then point it to the real gem on Rubygems or at some git repository).
For project structures, check out the Ruby Packaging Standard and Gem Patterns.