Improving the Drupal Developer Experience

Developing for Drupal can be exciting, but without a proper approach it can also get messy. Drupal is maturing and its developer community is growing and becoming more diverse as people from different software engineering backgrounds join. In addition, the number of modules produced is increasing, as is their complexity, especially as Drupal is required to integrate with external services and legacy systems. In the face of this it is crucial that, as a community, we ensure that the experience of coding for Drupal and the quality of the resulting modules continues to improve. If we neglect these issues, we risk negatively impacting Drupal by having poor quality modules and fewer developers wanting to join and dedicate time to the project. While, as a community, we have specifically focused on improving the Drupal site builder and Drupal designer experience, we should ensure that we don’t forget our main constituency: Drupal developers themselves. I am not talking about core developers or leading Drupal module developers. Rather, I’m referring to the thousands of Drupal developers who day-in and day-out build and expand Drupal modules whether custom or not - and how we as a community provide tools to allow them to do this work effectively. Furthermore, the types of tools I am referring to are not just things like more IDE plug-ins, more APIs, more documentation, more snippets and recipes; although all of these are part of the solution, we already have plenty of them. What is missing are wider-ranging conceptual tools that describe a rational and systematic approach to choosing and gluing together all the different systems and APIs that Drupal makes available in a way that can work well, can be shared across team members, and will naturally leads to better quality code. Such tools ultimately improve the developer experience as they reduce confusion, improve confidence in the choices made, and reduce the time it takes to develop. These tools are also more scalable, since they deal with overarching concerns and should survive specific Drupal versions. In particular, I am referring to the need for methodologies and patterns: Methodologies: guidelines, principles and methods that we employ to go from problem definition to solution. Patterns: proven reusable solutions to common problems. In the following paragraphs I will touch on each and give some examples of the types of things that we as a community could be discussing and presenting to help improve module development. I will leave more specific examples and a more in-depth analysis of the issues to subsequent blog posts.

Methodologies

A methodology is a process that accompanies us from problem definition to solution and provides tools that will allow us to do this in a consistent way. Underpinning a methodology are guidelines or principles that help us determine whether an approach is right or wrong. In the next couple of paragraphs I will give some examples of what could be valid principles to adhere to and what processes we could suggest. Here are three sensible principles to adhere to: Separation of concerns: are we performing actions at the right level? Is our module interacting with Drupal at the right point and through the right systems in order to do things such as access control, theming, interaction with the database, etc.? Decoupling: is our system flexible enough? Can different components be swapped out easily? Drupal is a mixture of OO and procedural code, so what are the best strategies for building decoupled systems in this rather unorthodox environment? Consistency: whatever approach we follow, it is important that we are consistent in how we name things, structure the location of files, and describe what we are doing. This makes it easier to share across teams. And here are some of the processes a methodology can introduce: 1. Always describe a problem in abstract terms first and not in "drupalese." This ensures that you have a clear definition that can be shared across a team and with a client. Consider the following two statements: A hotel owner needs to be able to display a list of available rooms with their associated descriptions given an arrival and departure date. Vs. I need to get all bookable unit entities and attach a field entity reference to them pointing to Room Description nodes that I can then render in Rooms view mode. The latter makes the mistake of describing the problem in terms of a possible solution. It’s also an example of how Drupal developers all too often liberally referring to nodes, blocks, panels and views instead of the things these tools actually provide (pages, components of a page, the structure of a page, and lists of things). The former, however, describes the problem in abstract terms, making absolutely no assumptions about how it could be solved, while using clear and precise language. 2. Always describe your architecture in generic terms first, and then in specific terms. Talk about storage, data structure, and interaction with other services without worrying about how that would be implemented in Drupal. Then translate that generic architecture into one that uses specific Drupal systems. This enables you to consider alternatives and once more avoids any assumptions about what a good solution would be.

Patterns

Patterns are a well-known concept in software engineering and probably one of the most effective tools we have to educate developers about good practices in developing software. Within the Drupal world I see the potential of identifying three different types of patterns that we can describe in generic terms, and accompanied with specific examples from modules that employ them so that developers can quickly learn how to use them. OO Patterns: Classical OO patterns are increasingly making their way into Drupal modules (a good example being the Entity API module). We should pull these out and explain how they can be used across different modules and situations. Drupal Patterns: There are certain patterns that seem to be Drupal-specific. An example would be the separation of a module's user interface and functionality in two different modules—such as the Views and Views UI module. We should identify more sensible solutions like these and explain how they can be easily implemented in any module. Service Patterns: Finally, some patterns are best described in terms of web service interactions and are most suitable to describe integrations with external services and Drupal.

Next steps

What I am trying to achieve here is not to formalize the Drupal module software development process and place a straitjacket around what a developer can do and how they should do it. Methodologies and patterns often run these risks, but they can be easily avoided by ensuring that the approach is light and flexible and focuses on underlying principles rather than complicated processes. Moving forward I would like to: focus on the following goals: 1. Document more patterns from the Drupal world and share those for comment. This is something that I started doing last year by looking at entities specifically. During a Drupalcon London presentation I talked about examples of how entities are used across different modules in order to inform how they can be used in your own modules. And just a couple of days ago at Barcelona Drupal Developer Days, I talked about the issues mentioned in this blog post, although in a more tongue-in-cheek way ;-). 2. Start working on a very lightweight methodology that we can use internally at Bluespark. 3. Identify other things such as module file naming, file structure, etc., that we could standardize within the wider community and which are not covered by the Drupal code style. If you find these problems interesting, please join in and post your suggestions about how to improve the developer experience in terms of methodology and patterns within the Drupal world.