• In Drupal: One big Feature or lots of little Features?

    Colan Schwartz argues that you should split up your Features for two reasons:

    • You’re including configuration information that you don’t care about, and
    • You’re making it difficult for developers to view differences between versions.

    I don’t agree with these arguments, but I do think there are good reasons to split your Features up.

    The configuration he is talking about is defaults that have since been overridden. Yes, these can bulk a feature up, but I’ve never actually found them to be a problem, they don’t show up in diffs and removing them is extra work that brings is own risk.

    His argument that it’s harder to see the differences suggests that a large feature will have more differences than a set of smaller Features, but taken as a whole this should not be the case. Each change you make will result in the same change in Features, although if you have separate Features you do have the option to revert/update them individually. Whatever the size of your Features you need to be disciplined to keep them in ‘Default’ state at all times (i.e. database and code are consistent), which isn’t always easy.

    My arguments

    I said I agreed that little Features are preferable, and there are three main reasons.

    Performance

    Once a Feature gets beyond a certain size Drupal can struggle to manage it, which can result in poor performance and/or out of memory errors. There is a balance to be had here though – if you have too many features you’ll wait ages for them all to show their Default vs Overridden status on the Features admin screen. I tend to favour drush features-diff anyway as it’s faster.

     Conflicts

    If you’re working in a team, or even just by yourself with multiple branches, then there’s a risk you’ll both make changes to similar areas. By making the Features smaller you reduce the chance that you’ll both end up making changes to the same feature. This can be particularly problematic if you forget to update your Feature before you pull you’re colleagues changes in code, as you’ll end up in the situation that neither database nor code contains the intended version of your Feature. If you find yourself in that situation you either need to go back to the older code, or do some fiddly manual merging.

    Reuse

    If you intend to use the same Feature on more than one site then you’ll obvious need to ensure it doesn’t contain anything that doesn’t apply to all sites. You’ll also need to make sure it doesn’t depend on any other Features, unless you also intend to share those Features.

    Categories: Drupal

    Tags: