Le guide technique de votre équipe pour réussir les codes reviews Drupal

Article rédigé par Brahim - Lead Développeur Drupal

Chez Actency, nous savons que la revue de code est bien plus qu'une simple validation technique. C'est un pilier essentiel du processus de développement logiciel, un moment d'échange qui renforce la qualité du code, la cohésion d'équipe et la sécurité des projets. Si vous travaillez avec Drupal et que vous cherchez à améliorer votre base de code et vos processus, vous vous êtes sans doute demandé quels points vérifier lors de l'examen des modifications.

Ce guide constitue une checklist complète et une référence pour tirer le meilleur parti de vos revues de code sur Drupal, de la création de la pull request à l'approbation finale.

Phase 1 : Préparer et ouvrir une pull request de qualité

Le processus commence avant même que la pull request (PR) ne soit ouverte. Une PR bien formatée et documentée est la clé pour streamliner la revue.

1. Avant d'ouvrir la PR : l'auto-revue

L'auteur doit se mettre à la place des autres membres de l'équipe (designer, relecteur, QA). Cette réflexion offre un nouvel éclairage et réduit le cycle de développement.

• Synchroniser avec la branche develop pour être à jour.
• S'assurer que le changement répond bien aux exigences documentées.
• Effectuer des tests de base et une vérification multi-navigateurs pour identifier les incohérences.
• Lancer un build de test pour vérifier que le projet se compile correctement.
• Exécuter les outils de linting et de standards de code (comme PHP_CodeSniffer avec le module Coder pour Drupal).
• Vérifier que les messages de commit sont clairs et utiles.

2. À l'ouverture de la PR : mettre le relecteur en condition de succès

Le but est de fournir un contexte immédiat et clair au relecteur.

• Rédiger une description utile : Expliquer le contexte, le "pourquoi" du changement, et inclure des points de discussion ou des questions. Un lien vers le ticket d'origine est un plus.
• Relire le diff attentivement : S'assurer qu'aucun changement unintended n'est présent (ex: formatage IDE, valeurs de configuration capturées par erreur). Vérifier particulièrement la cohérence des config splits.

Phase 2 : Revue de code : Une question d'empathie et de technique

Une revue de code est avant tout un feedback constructif, une opportunité d'apprentissage mutuel.

1. L'état d'esprit : Auteur et relecteur

• Pour l'Auteur : Approchez la revue comme une discussion. Expliquez votre raisonnement, écoutez les commentaires et considérez-les objectivement. Vous n'êtes pas votre code !
• Pour le Relecteur : Assumez la bonne intention. Posez des questions ouvertes, expliquez vos suggestions, et donnez du crédit quand c'est mérité. Votre objectif est de faciliter une discussion positive, pas d'imposer votre autorité.

2. La checklist technique de la revue

2.1. Approche générale

• La solution est-elle compréhensible et logique ?
• Accomplit-elle son objectif efficacement ?
• Contient-elle des fonctionnalités sans rapport ?
• S'inscrit-elle dans la stratégie globale du projet ?

2.2. La "Drupal Way"

Drupal est une boîte à outils. Il faut utiliser le bon outil au bon endroit.

• La solution exploite-t-elle les fonctionnalités existantes (Core > Contrib > Custom) ?
• Utilise-t-elle au mieux les API de Drupal ?
• Est-elle implémentée dans la bonne couche applicative (ex: thème, service) ?
• Supporte-t-elle une stratégie de gestion de contenu ?

2.3. Sécurité

La sécurité est primordiale. Vérifiez que les API de Drupal sont utilisées correctement.

• Les requêtes SQL utilisent-elles la Database API ?
• Les API de texte (t()) sont-elles utilisées pour échapper le contenu ?
• Le contenu est-il rendu via Twig (qui escape automatiquement) ?
• Les permissions et contrôles d'accès sont-ils correctement implémentés ?
• Les endpoints API (JSON:API) ont-ils des filtres d'accès et de données appropriés ?

2.4. Approche API-first et architecture

Le code doit être réutilisable et maintenable.

• Les composants sont-ils correctement (dé)couplés ?
• L'injection de dépendances est-elle utilisée correctement ?
• Les nouveaux composants sont-ils abstraits via une interface ?
• Évite-t-on les hooks legacy quand une approche moderne (ex: plugins, services) est disponible ?

2.5. Documentation

Cruciale pour les développeurs actuels et futurs.

• Les PHPDoc sont-ils présents et complets (fichiers, classes, méthodes) ?
• Les blocs de code complexes sont-ils expliqués par des commentaires ?
• Les contournements (workarounds) font-ils référence à un ticket ou une documentation ?
• Les nouveaux types de contenu ou variables de configuration sont-ils documentés dans l'UI ?
• Le fichier .info.yml du module est-il correctement renseigné ?
• Un fichier README est-il inclus si nécessaire ?

2.6. Standards de code

La cohérence améliore la lisibilité et l'intégration.

• Le code suit-il les standards Drupal/PHP et ceux de l'équipe ?
• Les noms de variables, fonctions et classes sont-ils appropriés ?
• Les outils de validation automatique (PHP_CodeSniffer) ont-ils été exécutés sans erreur ?
• Le changement inclut-il des modifications de formatage inattendues ?

Conclusion : Améliorez votre base de code et vos processus

Ce guide technique est conçu pour être une référence que votre équipe peut consulter à chaque nouvelle revue de code. En intégrant ces bonnes pratiques à la fois techniques et humaines vous faciliterez des conversations saines au sein de votre équipe de développement.

Le résultat sera tangible : une base de code Drupal plus sécurisée, plus efficace et plus facile à maintenir sur le long terme.

Vous souhaitez échanger avec un expert ?
> Contactez un expert Drupal