30+ small modules versus 5 large modules versus 1 HUGE module: Which is better?

Question

So, we have a large, complex Drupal 6 site, which has lots of secret sauce and magic glue making it work.

Where we can, we've contributed modules back and made them generic, but we still have 30 or so custom modules to keep it working the way we need it to. Each module (in most cases) has a specific function e.g. our hook alters for the notification system.

We are doing a huge code review at the moment and looking at improvements we can make. One thing suggested is to merge the large number of modules into a few smaller master modules, with lots of include files. We would, perhaps group by general site area e.g. "community", "admin" and "messaging", instead of specific modules per functionality.

1. Is the effort in doing this worth it? Will it speed up the site?
2. What module grouping would you recommend?
   • by site area ("community", "admin", "upload")
   • by hook ("form", "node", "user", "theme")
   • everything in one module
   • something else?
3. What naming conventions should we use for the include files to keep the codebase sane?
4. Am i right in assuming the goal should be tiny .module file with includes per hook / menu / area?

Answer 1

It sounds like you don't really know what your bottleneck is. This restructuring will likely have very little impact on performance (unless you happen to find and trim some major bloat in the process), but it may make things easier for you to maintain. If you do decide to restructure I would recommend splitting up along "site features" (blog, image galleries, etc.).

But if performance is your concern you first have to diagnose the problem before you attempt surgery.

Answer 2

Modules should do one thing, and one thing well. The "thing" should be a piece of functionality on the site. That module should include all of the hooks to do that one thing. As much as possible, disabling a module should have limited side effects on the site, and should be limited to just disabling the "thing".

Ask yourself:

Can I have multiple hands in the project with how I am splitting / combining modules?

If I need to change the module a year from now, am I going to have an easy time honing in on where things are implemented?

If I need to edit some code, am I going to have to be worried about mucking up another feature (think shared hooks like form_alter, block_view, etc)?

I always choose ease of maintainability over minute performance impacts on a site.

Answer 3

You'll need to carry out performance testing to answer the question of if it will speed up the site. Search for Mark Sonnabaum's recent XHProf presentation, as this is a painless way to do so.

Another approach beyond the ones suggested that you could take is seeing if you can now re-implement any of your custom code using contributed modules. Rules, Views, and other contributed modules have probably come a ways since you first wrote your code, so this could be another way to simplify, although you will likely end up exporting those configurations again with Features anyway :) - still, at least it'll be a bit less code/configuration for you to maintain in the end if that's one of your goals.

Answer 4

Using the Drupal core code as example, each module should implement independent functionalities. For example, in Drupal, the module for handling the taxonomy term is the Taxonomy module; it is not the Node module that include that functionality in its code.

The question is then, when do you split a module in two, and when do you keep the code in the same module?

• If the code that should go in the new module is just few lines, then the code should be kept in the old module.
• If in the old module you keep writing in different hooks is similar to if ($option_enabled) { /**/ }, then the code should be written in a new module; in this way, instead of having a module that tests if the functionality has been enabled, the administrator users enable the new module if they want the functionality.

Keep in mind that, when you split code in two modules, the main module should not depend from the secondary module, but vice versa. This means the main module should not verify the secondary module is enabled before to execute some code; if this happens, you should consider re-write the code to use a hook that is then implemented from the secondary module.

Between the following snippets, the second is preferable.

if (module_exists('secondary_module')) {
  // Code that requires the secondary module.
}

// Invokes the hook that is implemented by the secondary module.
module_invoke_all('hook_name');