Driving Drupal Best Practices

Business is hopping. You’re hiring Drupal developers with varied backgrounds and skill sets. 

When working in Drupal, there are often many ways to achieve the same outcome, and quite often, Drupal developers find themselves on different pages. How do you determine whose way is the 'best' way and proceed with optimal efficiency?

There are two perspectives to consider:

• A team executing best practices, and
• The process(es) needed to get best practices into place.

Best Practices

When defining the best practices that your Drupal development team will follow, you need to consider the following areas of development:

• Foundational Strategies
• Common Feature Configuration Options
• Standard Methods for Selecting Contributed Modules
• Custom Coding Standards
• Development Environment
• Workflow Methodologies
• Testing and Quality Assurance

Foundational Strategies

All Drupal sites have a set of features that are the same. For instance, most, if not all, sites: 

• Use content types to create content pages
• Have a search functionality
• Need a custom theme
• Must meet WCAG 2.1
• Should be usable

Before the discovery phase of a project, where requirements are confirmed and refined, create a set of configuration and coding defaults that allow you to deliver a quality product, and enable non-developers to easily use the site.
 

Common Feature Options

There are multiple ways to develop features in Drupal; some good and some not so good. Although there might be exceptions to this rule, choosing one way to develop a feature across your projects will help ensure your product is the best it can be.

Start with consistent configuration strategies and contributed modules. Consider the following:

• Low maintenance is key to sustaining a site and continued services.
• End user processes and skills take precedence over what’s easy for a developer to do.
• Security can be in jeopardy with custom solutions. 

When collecting requirements, compare what’s needed with the one or more strategies you have placed in your company toolbox. Use only an approved strategy unless the requirements can’t be met.

Standard Methods for Selecting Contributed Modules

When a requirement can’t be met with a feature configuration option already in your toolbox, it’s time to go looking for options within the many contributed modules. This is a time when your sought-after best practices can go out the window if you aren’t careful.

Evaluating contributed modules in an effort to meet requirements should be a consistent process. It should be a process that not only helps configure the appropriate solution, it should also yield a configuration option for future projects.

New “best practices” should consider the following:

• The common features considerations suggested above
• Pros and cons of each module that meets your needs, maturity, flexibility, and coding standards
• The history of the contributed module developer(s) and their ability to maintain the module
• Whether your team is ready to take up the mantle of maintenance if needed
• The interaction the module(s) could have with other features on the site

Custom Coding Standards

You have exhausted options using Drupal’s core and contributed modules and still have requirements that need to be met. This is where custom code comes in. 

The Drupal community has shared numerous standards for code development for Drupal. You don’t have to reinvent this wheel. However, you do need to establish a process that ensures:

• Decisions to use custom code are appropriate
• Drupal coding standards are being followed

Establish a set of criteria that must be met before custom code is cut. Asking questions such as the following can kick off your evaluation process:

• Which modules (core and contributed) have been assessed as a means of meeting the requirement?
• Why won’t existing modules work?
• Can existing modules be modified to meet the need?
• Does the client want this specific custom solution or do they want to adjust the requirement?
• What are the potential security and maintenance issues associated with the custom code that can surface during the life-cycle of the website?

Development Environment

Before you can use the above best practices, you need a development environment. 

Drupal can run in many different web server configurations, but there are server settings that maximize Drupal’s performance. Invent your own server or use a service designed specifically for Drupal, that’s your choice.

In order to develop a website that can be hosted by your client, you need to know what their server environment will look like. If it varies from the solution you have selected, you will need a process that allows for:

• Best practice configuration and coding that can be executed
• The solution to be tested on the client’s server environment
• Multiple developers to participate in development without creating issues

Workflow Methodologies

None of the above will matter if you don’t have a workflow that supports the best practices you have set forth for your team. If your developers don’t have time to evaluate their options, consult with each other, or document their solutions, they will do what they can in isolation.

Workflow is about establishing a consistent way of working, while taking into consideration tested and tried software development methodologies. You don’t have to use what others are promoting. You can mix it up, or adjust to meet your needs.

Whatever the workflow you define, consider allowing time to:

• Identify and create best practices
• Test new practices for coding standards
• Verify requirements have been met
• Provide quality foundation configurations, those your client assume you will deliver

Testing and Quality Assurance

Testing and QA are part of a defined workflow. However, they are worth mentioning separately as each process can overlook issues if not done correctly. Therefore, when creating a workflow, ensure you have best practices in place, particularly those accepted by the software industry.

Such testing and QA processes should consider:

• Automated and manual testing of accessibility
• User acceptance testing
• Common software testing such as unit, integration, system, sanity, smoke, interface testing, and regression

Getting Best Practices into Place

Are you sold? Do you see the logic in the above best practice categories? Great. The next question you might have is how to implement it. 

There is no one way. However, there are basic steps you can take to get started. Remember, change isn’t going to happen over night. Incremental change is an option, unless radical improvement is needed now. If this is the case, re-engineering is your best option.

One way to kick off the process of change is to perform the following tasks:

1. Get your developers into one room
2. Make a list of the most common feature requirements
3. Identify strategies for meeting the common features
4. Rank the strategies by the requirements met
5. Document the strategies 
6. Train your staff
7. Meet regularly to learn from each other, to add new options, and improve existing strategies
    

Conclusion

This idea of consistent process improvement to help ensure a quality standard that has its roots in the Capability Maturity Model Integration (CMMI), which dates back to 1987.  CMMI is a process level improvement training and appraisal program and could be of assistance as you set goals for your organization.

Whatever you choose to do, change for the sake of quality improvement can only lead to:

• Continued business growth
• Happy customers
• Employee job satisfaction

Promet Source offers a depth and breadth of Drupal development expertise. Contact us today to schedule a workshop or for information and insights to ensure that the agility and reach of Drupal is being fully leveraged.