6 techniques de refactoring de code pour WordPress

Six techniques de refactoring de code déterminent si un codebase WordPress reste maintenable après sa première année de vie, ou s'il devient ce functions.php que les prochains freelances héritent avec appréhension. Un fichier qui dépasse 400 lignes est déjà un signal fiable. Il en va de même pour un pattern de bloc dupliqué « temporairement » il y a trois mois et qui existe désormais en cinq versions légèrement différentes dans le dossier du thème d'un client. Ce folio couvre les techniques qui comptent réellement, appliquées au développement de thèmes de blocs et au PHP de plugin.

Le signe qui indique qu'il est temps de refactoriser

Les code smells ne sont pas des bugs. Le site tourne. Le client est content. Mais le prochain développeur qui touchera ce codebase passera quatre heures à comprendre ce qui devrait prendre quarante minutes.

À l'usage, voici ce que l'on constate : le coût du refactoring grimpe fortement plus on le repousse. Une enquête Stack Overflow de 2024 relève que 62 % des développeurs citent la dette technique comme leur principale friction quotidienne. Sur des projets WordPress, cela se traduit généralement par une logique conditionnelle imbriquée sur quatre niveaux dans une fonction de template, ou par des appels à register_block_pattern() dispersés dans trois fichiers différents sans propriétaire clair.

Le prérequis avant toute technique : la couverture de tests. Refactoriser sans tests n'est pas du refactoring, c'est de la réécriture optimiste. Pour WordPress, WP-CLI et PHPUnit posent la base. Sur les thèmes de blocs full-FSE où le PHP est minimal, des vérifications de bout en bout via Playwright contre un environnement Lando ou LocalWP local rendent le même service.

Extract Method : le premier outil sur l'établi

La technique de refactoring la plus largement applicable en PHP WordPress est l'Extract Method. Le principe est direct : quand une fonction fait plus d'une chose, on la découpe.

Prenez un gestionnaire d'upload de fichiers dans un plugin. La version d'origine est une fonction de 200 lignes qui valide le type MIME, vérifie la taille du fichier, détermine l'ACL S3 et écrit les métadonnées de la pièce jointe, le tout en séquence. La version refactorisée définit quatre méthodes : is_valid_mime_type(), is_within_size_limit(), get_s3_acl() et write_attachment_meta(). La fonction principale se lit presque comme une prose annotée.

Pour les thèmes de blocs Gutenberg, le même principe s'applique à functions.php. Un thème qui enregistre des styles de blocs, charge des scripts d'éditeur, configure des supports de bloc et ajoute des variables de requête personnalisées dans un seul hook after_setup_theme en fait trop d'un coup. Séparer tout cela en fonctions nommées et ciblées, incluses depuis un dossier /inc/, n'a rien d'une architecture astronautique. C'est la différence entre un codebase qu'on reprend en une heure et un codebase qui exige une visite guidée.

Marginalia : cette approche vaut pour WordPress 6.4 et suivants, où l'API des block hooks introduit des schémas d'enregistrement supplémentaires qui bénéficient de cet isolement.

Les clauses de garde remplacent les conditions imbriquées

Les conditions imbriquées constituent la deuxième friction la plus fréquente dans le PHP WordPress observé en production. Un schéma récurrent en développement de plugin : une fonction vérifie une capacité, puis un type de post, puis une valeur de méta, puis exécute enfin sa logique. Chaque vérification est imbriquée dans la précédente, produisant un code en forme d'escalier.

Les clauses de garde inversent ce schéma. Chaque condition qui empêcherait l'exécution devient un retour anticipé en tête de fonction. Le chemin heureux se retrouve en bas de la fonction, sans indentation, lisible sans avoir à suivre la profondeur des accolades.

// Avant : l'escalier de la damnation
function handle_submission( $post_id ) {
    if ( current_user_can( 'edit_posts' ) ) {
        if ( get_post_type( $post_id ) === 'project' ) {
            if ( get_post_meta( $post_id, '_status', true ) === 'pending' ) {
                // logique métier ici
            }
        }
    }
}

// Après : clauses de garde
function handle_submission( $post_id ) {
    if ( ! current_user_can( 'edit_posts' ) ) return;
    if ( get_post_type( $post_id ) !== 'project' ) return;
    if ( get_post_meta( $post_id, '_status', true ) !== 'pending' ) return;

    // logique métier ici
}

La version refactorisée est plus courte et, surtout, chaque condition peut être lue, comprise et modifiée indépendamment. Quand la logique métier change (elle changera), la modification est chirurgicale.

DRY dans les patterns de blocs : cessez de dupliquer vos templates

Le principe DRY (Don't Repeat Yourself) est celui que l'on viole le plus souvent en développement de thème de blocs. Quand un freelance WordPress construit un site pour un client, la bibliothèque de patterns initiale grandit souvent de façon organique : un bloc hero ici, une section de témoignages là. Au troisième mois de développement actif, il est courant de trouver cinq variantes de bloc hero avec 80 % de balisage identique, chacune légèrement adaptée à une section différente du site.

L'approche de refactoring consiste ici à identifier la structure commune, à l'extraire dans un pattern canonique unique, puis à utiliser les variations de pattern de bloc ou les styles globaux pour gérer les différences visuelles. C'est ce que facilite le plugin Create Block Theme au niveau de l'outillage : il rend explicite l'écart entre un « thème en développement » et un thème exportable et réutilisable.

Pour le PHP de plugin, l'équivalent consiste à extraire les méthodes partagées dans une classe parente. Si deux classes d'extension définissent chacune une méthode set_settings() qui lit la même clé d'option, cette méthode appartient à une classe abstraite partagée. Quand la clé d'option change, la correction s'applique une seule fois.

Sautez ce refactoring si les patterns dupliqués servent des contextes éditoriaux réellement distincts qui évolueront indépendamment. Un DRY forcé crée un couplage pire que la duplication d'origine. Le test : est-ce que les deux duplicatas changeraient logiquement ensemble ? Si oui, extrayez. Sinon, laissez-les séparés.

Refactoriser les templates FSE : du monolithe aux template parts

Le système de templates Full Site Editing a introduit une opportunité de refactoring structurel que de nombreux développeurs de thèmes de blocs n'exploitent toujours pas pleinement. Un fichier templates/single.html qui contient tout le balisage du header, la navigation, la zone de contenu, la sidebar et le footer en un seul fichier est l'équivalent FSE d'une fonction monolithique. Cela fonctionne. C'est aussi impossible à maintenir sur un site qui compte douze types de post différents.

Le chemin de refactoring, ce sont les template parts. On déplace le header dans parts/header.html, le footer dans parts/footer.html, et on les référence via <!-- wp:template-part {"slug":"header"} /--> dans chaque template qui en a besoin. Quand le client modifie la structure de navigation, la modification se fait dans un seul fichier et se propage partout.

Ce n'est pas hypothétique. La documentation du Block Editor sur les template parts confirme ce même principe de composition, appliqué cette fois au cœur de WordPress.

Une remarque de terrain sur les cas où il ne faut pas refactoriser les templates : si un site compte dix templates légèrement différents et que le client les édite fréquemment lui-même dans le Site Editor, une extraction agressive en template parts peut créer de la confusion. L'interface du Site Editor pour les template parts s'améliore mais présente encore des frictions de découvrabilité. Pour des clients non techniques, moins de pièces mobiles est souvent le bon choix, même si c'est architecturalement moins élégant.

Les méthodes PHP fonctionnelles réduisent l'encombrement des boucles

Les fonctions natives de tableaux de PHP (array_map, array_filter, array_reduce) sont sous-utilisées dans le code de plugin WordPress. Elles éliminent les boucles foreach explicites et les variables intermédiaires, produisant un code qui exprime l'intention plutôt que le mécanisme.

Un schéma courant sous WordPress : parcourir un tableau d'objets post pour en extraire une valeur calculée, en construisant un accumulateur à l'intérieur de la boucle. L'équivalent fonctionnel utilise array_map pour transformer chaque post et array_reduce pour calculer la valeur finale. Le résultat : moins de lignes et, surtout, aucun état mutable à l'intérieur de la boucle.

Cette technique convient quand l'opération est réellement une transformation ou une réduction. Elle ne convient pas aux opérations à effets de bord (écritures en base, appels API) qui nécessitent une gestion d'erreur par élément. Dans ces cas-là, la boucle explicite avec des limites d'erreur claires reste le bon choix.

theme.json comme refactoring de design tokens

La sixième technique est spécifique au développement de thème de blocs et représente un type de refactoring différent : sortir les valeurs codées en dur du CSS et du PHP pour les déplacer dans theme.json sous forme de design tokens nommés.

Un thème qui définit color: #1a1a2e dans six règles CSS différentes, ou qui code en dur la même pile de polices à la fois dans style.css et dans une feuille de style d'éditeur, a un problème de maintenance. Quand la couleur de marque change, le développeur cherche des valeurs hexadécimales. Quand la police change, elle change à deux endroits ou plus.

theme.json résout cela en rendant les décisions de design explicites et nommées. Une entrée de palette "slug": "primary" devient var(--wp--preset--color--primary) en CSS. Changez la valeur hexadécimale dans theme.json, et chaque bloc qui utilise la couleur preset se met à jour automatiquement, à la fois sur le site public et dans le Site Editor.

Le même principe s'applique aux échelles d'espacement, aux tailles de police et aux dimensions de mise en page personnalisées. Refactoriser un thème pour utiliser les tokens theme.json de façon cohérente n'a rien de glamour. Cela prend du temps. À l'usage, voici ce que l'on observe sur les sites où c'est fait : la prochaine itération de design est mesurablement plus rapide, et l'écart de style entre l'éditeur et le site public diminue nettement.

Quand le refactoring aggrave la situation

Le colophon de cet article : tous les codebases ne bénéficient pas d'un refactoring agressif. Trois situations appellent à la retenue.

D'abord : un site client avec une échéance de livraison dans deux semaines. Le refactoring introduit du risque. Livrez la fonctionnalité, documentez la dette, planifiez le nettoyage.

Ensuite : du code que vous ne comprenez pas encore complètement. Refactoriser exige un modèle mental de ce que fait le code. Si ce modèle est incomplet, la version refactorisée risque de supprimer un comportement qui semblait accessoire mais portait en réalité une charge fonctionnelle.

Enfin : du code qui sera remplacé entièrement d'ici six mois. Les données McKinsey de 2024 sur le refactoring systématique montrent un taux d'achèvement 40 à 50 % plus rapide comparé à des approches ad hoc. Cet avantage suppose que le code refactorisé continuera d'être maintenu. Si le code est temporaire, l'investissement ne se capitalise pas.

Le test avant de refactoriser un codebase WordPress : pouvez-vous formuler, en une phrase, ce que fait le code aujourd'hui ? Si non, lisez avant de réécrire.