Sujet : refactoring
-
Refactoriser par petites étapes vérifiées
La refactorisation modifie la structure sans changer le comportement ; procéder par petites étapes avec des tests réussis entre chacune, et séparer les commits de refactorisation des changements de comportement, permet de la sécuriser et de faciliter sa revue.
-
Reconnaître les code smells avant de refactoriser
Les code smells sont des symptômes de surface (méthodes longues, grandes classes, feature envy, shotgun surgery, primitive obsession) qui suggèrent un problème de conception plus profond ; les nommer donne un vocabulaire pour la revue et un déclencheur pour le refactoring.
-
Le refactoring par petites étapes vérifiées
Le refactoring change la structure interne, pas le comportement observable. Un refactoring nommé du catalogue après l'autre, des tests au vert après chaque étape, un retour en arrière plutôt qu'un débogage en avant au rouge, des changements de structure et de comportement dans des commits séparés – ainsi, le travail reste sûr et vérifiable en quelques minutes.
-
Tests de caractérisation : figer ce que fait réellement le code hérité
Avant de modifier un code dont le comportement voulu est inconnu, écrire des tests avec des attentes provisoires, lire la sortie réelle dans l'échec du test, la consigner comme attente, et nommer le test d'après ce que fait le code ; les surprises sont journalisées, pas corrigées, en attendant la décision des personnes responsables.
-
Remplacer un système hérité avec le patron du figuier étrangleur
Plutôt qu'une réécriture en une seule fois, router les fonctionnalités une par une, via une façade, vers une nouvelle implémentation, jusqu'à ce que l'ancien système ne porte plus aucun trafic et puisse être retiré.
-
Construire des données de test avec des builders : valeurs par défaut valides, écarts nommés
Un builder de données de test fournit, pour chaque entité, un objet standard valide, et ne laisse le test définir que les champs dont dépend son assertion. On lit ainsi dans le test ce qui compte, et une nouvelle colonne obligatoire ne change qu'un seul endroit au lieu de cent tests. La démarche se distingue des fixtures partagées et de l'Object Mother, dont Martin Fowler décrit le couplage étroit.
-
Les builders de données de test avec valeurs par défaut réduisent la casse des tests lorsqu'un objet du domaine change
Hypothèse : les suites qui construisent leurs objets via des builders, où chaque champ a une valeur par défaut valide et où un test ne définit que les champs sur lesquels porte son assertion, nécessitent moins de modifications de test par changement de schéma ou de constructeur que les suites reposant sur des fixtures partagées ou des Object Mother à instances toutes faites.
Lisible par machine : JSON