Julien Dubois
Cet article a été initialement rédigé pour Drupal 8 mais son contenu est toujours d'actualité pour Drupal 9 et Drupal 10.
Combien parmi vous se revendiquent “développeur Drupal” plutôt que “développeur PHP” ? Cela est probablement dû au fait que Drupal fonctionne grâce à un certain nombre de couches d’abstractions qui lui sont propres et que si demain vous étiez privé(e) de Drupal vous vous sentiriez démuni(e) sans Form API, Entity API, Views ou Batch API.
En pointant cela du doigt on se rend compte de la richesse d’un outil mais on peut aussi se demander si cela n’est pas une erreur. En utilisant un composant drupalo-drupalien, vous ne pourrez pas vous en resservir en changeant de technologie et c’est bien dommage. C’est une des raisons pour lesquelles Drupal à partir de sa version majeure 8 s’est ouvert sur le monde extérieur. Pouvoir bénéficier de composants connus et réutilisables. On parle ici de Twig, de HTTPKernel et HTTPFoundation, de l’autoloader PSR, de Guzzle, etc. D’ailleurs tout n’est pas à jeter dans Drupal, si Views devenait un composant proprement découplé il pourrait être réutilisé dans d’autres applications. Les développeurs de Commerce 2.x sont dans cet état d’esprit de design par composants indépendants et réutilisables et il est probable que cela soit une tendance de fond sur les années à venir.
L’idée derrière cela est qu’il faut garder à l’esprit qu’à chaque fois que nous concevons un nouveau projet web avec une valeur ajoutée métier, nous devons réfléchir à son architecture. Trop souvent cela se résume à choisir les modules contribués sur lesquels nous reposer, combien de modes d'affichage à créer par type de contenu ou s’il faudra utiliser Paragraphs VS des templates VS UI suite (troll en approche).
Une application web est composée d’objets et il y a des liens entre ces objets. Si vous utilisiez un framework il faudrait pondre un diagramme de classes et un schéma de base de données, designer vos interfaces pour rendre votre code élégant et structuré. Drupal 7 a apporté les trop peu utilisés types d’entités, profitez en pour vous poser la question du bon stockage de vos données (bundle de nœud VS nouveau type d’entité VS simple table).
Trop souvent le code est fragmenté et manque de recul. Pour savoir si votre application est de qualité, il suffit de vous demander cela : “suis-je capable de faire du refactoring ou de modifier des pans capitaux de l’application tout en restant serein(e) ?”. Dans la plupart des cas la réponse sera non. La faible couverture de tests (unitaires ou fonctionnels) en est l’une des principales explications. Pour cette raison, plus vous suivrez un modèle clairement défini en amont et partagé par l’équipe plus vous serez en maîtrise de votre application et, qui sait, si votre processus de production est très avancé vous réussirez à produire des tests !
Concevoir une application c’est se demander quel est le bon outil pour un usage donné. Lorsque vous designer l’infrastructure nécessaire pour faire tourner votre application vous piochez parmi des outils tels que Varnish, Nginx, Memcache, Redis, Solr.. faites la même chose sur la partie PHP. Il sera parfois plus simple d’utiliser une autre technologie voire un autre langage ou s’appuyer sur une librairie externe plutôt qu’un module Drupal pour adresser certaines problématiques. L’important est de pouvoir faire communiquer tout ce petit monde ensemble et la bonne nouvelle c’est que les webservices se sont démocratisés (encore faut-il bien les designer), facilitant par la même occasion l’échange de données. Et si vous en venez à écrire vos propres solutions, pensez à les partager, c’est la clé de l’Open Source.