Did you know there are nearly 22,000 contributed modules listed on Drupal.org? Finding modules which you can be confident to suit your needs is not a trivial task.
Popularity and Familiarity
Right off the bat there is a generally agreed upon set of modules that people just install on most projects. We're talking about Views, Ctools, Token, Pathauto, Date, Webform, etc. Obviously you don't want to install something that's not needed but these are modules that have withstood the test of time and usage, and have fairly well-defined capabilities. So if I want a web form on my site to collect a little bit of data, BOOM Webform module is installed. It really is that simple.
Drupal developers who have been aroud a while have a large bag of tricks which they've built through experience. Whether it's playing around on test sites or managing live installations, over time you'll gain familiarity with various modules be confident in what you'll get out of it. On a similar note, over time you'll also likely develop aversions--founded or not--to certain modules and you'll know which ones you want to avoid.
Drupal.org Project Page
Without even looking at the code you can get some good insight as to it's quality just by a quick look at the module's page on Drupal.org. Right there on the front page there is data about how many sites are running the module and how many issues and bug have been reported. Granted it's not the end-all, but the number of open bugs to sites running a module is a fairly significant metric. If there are a lot of issues reported an not many people using it, you better think twice.
Beyond the raw numbers you can also look through the issues in the queue to get a good sense of what types of issues people are having and if those issues may apply to you. This also should give you a good sense of how active the maintainer is and what kind of feedback to expect.
Also on the project page you may be able to find links to tutorials and documentation. It doesn't get much better than having the author of a module provided you with details of how it works. Sometimes you can even find videos that walk through the configuration and operation of a module.
When you install a module on a Drupal site, you're literally putting code into the execution of Drupal. So even if you're not a developer, if you're in charge of managing the site you're also responsible for the code that running on the site. If you install something that drops your node table, then well, hey, sorry. I hope you know how to fix that.
The ecosystem of Drupal projects encourages community feedback and participation in crafting quality, performant and secure code. But let's be honest, there are still some clunkers out there. Every module is a little different, but there are a number of things I like to look at to determine what a module does,
- Sane, understandable comments Developing should be like doing magic, tell us what you're going to do then make it happen.
- hook_menu() See what page callbacks the module exposes. This will give you a good idea of what kind of functionality the module adds to the user experience and which configuration screens are available.
- hook_form_alter() This is another common method of handling configurations.
- hook_permission() See what kind of user actions the module supports.
- hook_init() and hook_boot() Operations that occur on every request that Drupal handles are worth noting.
- hook_node_load() and hook_entity_load() A common pattern is for modules to step in during a load hook and set additional data on the object. In many cases it's unavoidable but it's a good idea to be aware of it and to give it a quick sanity check.
- Caching Look to see if there are common routines that load or compute data and see if that value is being cached at the request level (static variable or drupal_static()) or persistently cached (cache_get()/cache_set()).