Contexte

Cette méthode est utilisatble pour les développeurs de site Drupal 6 ou 7 déjà en production (qu'on ne peut pas updater en Drupal 8). Ou pour ceux qui continuent de faire du Drupal 7 aujourd'hui, et qui n'ont pas les moyens de construire le site en Drupal 8 en parallèle. Cette méthode est utilisable jusqu'à l'utilisation de Drupal 8 en production directement.

Périmètre

On se concentre sur le code uniquement métier, le reste n'étant pas réutilisable. On va avoir, appoximativement :

• 70 à 80% de code orienté objet réutilisable ;
• 10 à 15% de code lié à la configuration (qu'il faudra migrer en CMI) ;
• 10 à 15% de code à usage unique remplacé complètement en Drupal 8 (code complètement perdu).

Avertissement

Attention de ne pas en faire trop (inutile par exemple d'utiliser le module Twig en Drupal 7, il est probable que la couche front sera de toute façon refaite en Drupal 8, inutile également d'essayer de réécrire CMI ou WSCCI en D7).

Boîte à outils

• git (surtout en utilisant des dépots isolés pour le code métier et des submodules Git pour les inclure) ;
• composer (et la clause repositories du composer.json) ;
• utiliser un class-loader PSR-4 (celui de Composer, disponible sur Drupal 6 également) ;
• pour les tests unitaires : PHPUnit ;
• pour les tests fonctionnels : Behat (sera peut-être un standard D8 standard (voir #2302545), Mink & Goutte y sont déjà).

Back-end

L'idée est de considérer que le module (au sens du fichier .module) Drupal ne représente que la partie du code qui ne sera pas récupéré, et implémente juste des bouchons :

• implémenter les hooks pour récupérer les bons paramètres
• récupérer une instance de ServiceManager
• invoquer une méthode sur l'instance en lui passant les paramètres du hook.

La logique métier est donc dans des méthodes d'instance.

"Don't be STUPID, be SOLID"

STUPID et SOLID sont deux acronymes représentant une liste de pratiques. Les STUPID sont plutôt à éviter. Frédéric (et d'autres) préconisent plutôt d'adopter SOLID (dont les 2 premiers sont les plus importants) :

• Single-responsibility principle : chaque classe est en charge d'une seule chose (une classe par formulaire, une classe par block, un controller pour les pages d'administration, un pour les pages standard, un ServiceManager par service).
• Open / Closed principle : Open for extension, Closed for modification, recommande l'utilisation d'Interfaces.

Pour les logs, utilisez le standard PSR/3 (par exemple la librairie Monolog).

Certaines des fonctions Drupal peuvent vous manquer : t(), variable_…, cache_…, url(), l(). La meilleure solution est pour cela d'implémenter un sous-ensemble du \Drupal de Drupal 8 (et pas plus que ce dont vous avez besoin !).

Pour le stockage !

• Utilisez des entités : en utilisant l'Entity API, vous pourrez implémenter des classes que vous pourrez réutiliser en Drupal 8.
• Séparez votre "configuration" entre configuration, état & paramètres, pour les adapter plus rapidement en D8.

Front-end

Javascript

Pas de plan spécifique. Essayez simplement d'utiliser les dernières versions de toutes vos bibliothèques et de limiter votre utilisation de jQuery.

CSS

Adoptez des principes SMACSS.

Theme

N'utilisez pas de fonction process_*, n'utilisez que du preprocess_*.

Retours d'experience

Tout cela est difficile, vous aurez probablement à aider les développeurs habitués aux anciennes pratiques.

Cela dit, cette technique a déjà été utilisée au moins deux fois :

• Certaines bibliothèques développées pour Commerce 2.x sont également utilisés par Sylius ;
• Pour un système de commentaires sur un gros projet français : au final, 23% de code à jeter, et 77% de code réutilisable.