Legacy-Code

• existant ?
• de mauvaise qualité ?
• vieux ?
• on ne sait pas ce qu'il fait ?
• plein de dépendances ?

Legacy-Code

Du code sans tests

La seule vérité est le code

Les specs ne sont pas à jour et pas fiables

Ne rien changer au fonctionnement

Un bug suffisamment vieux devient une feature

Toujours demander au PO

Pourquoi refactorer ?

Le code fonctionne très bien, ne pas refactorer pour le principe.
C'est couteux et risqué.

Pour comprendre le fonctionnement ?

Pour ajouter une feature ?

Pour rembourser la dette ?

"Make the change easy before making the easy change."
Kent Beck

Gestion de version

Pouvoir toujours revenir à un état stable.

S'autoriser à refactorer, renommer, bouger des choses pour rien, juste pour découvrir le code.

Time-boxer

Bloc-notes

Golden Master Test

Le système est une boite noire, on vérifie que pour les mêmes entrées on a toujours les mêmes sorties

• Librairie Approvals
• Fixer les entrées
• Sérialiser les objets, ou rediriger les sorties pour avoir du texte
• Vérifier avec la couverture de code. Attention, pas toujours fiable
• Vérifier en changeant des bouts de code. (Red du TDD)
• Utiliser des données représentatives (copie de prod)
• Vérifier qu'on ne touche pas d'environnement de prod.

Test de caractérisations

Créer une batterie de tests unitaires qui permmettent d'avoir des specs.

Rendre le code testable en supprimant les dépendances

• Extraire les appels statiques dans des méthodes protected
• Utiliser uniquement les refactos automatisé de l'IDE
• remplacer les "new Object()" par des paramètres
• Utiliser l'héritage

Commencer par tester la branche la plus courte

La branche avec le moins de complexité (for, if...) et la plus facile à tester.

Utiliser la couverture de code pour voir les branches qui ne sont pas encore testées.

En dernier recours

Reflection

Mock d'objet statiques

Refactorer

Baby-steps

Tester en continu

Nommer les choses

• Commenter pour donner un nom a un paquet de lignes, à un chiffre
• Extraire ces lignes dans une méthode, une variable
• Donner comme nom à la méthode/variable le commentaire
• Supprimer le commentaire

Comprendre ce que fait le code et mettre cette compréhension dans le code.

Extraire des méthodes

Commencer par les branches les plus à droite (les plus imbriquées) et par des tous petits blocs.

Extraire des variables, forcer la visibilité du vide pour faire apparaitre de la duplication.

Améliorer le design

• Casser les appels à l'extérieur (Logs, BDD, fichiers, mails ...)
• Casser les appels statiques
• Mettre de l'injection de dépendances
• Extraire des objets

Objets

• Profiter de la création d'objets pour faire du TDD et mettre des tests unitaires.
• Procéder par toutes petites itérations : encapsuler un String dans un Objet, puis rajouter d'autres champs, des méthodes ...
• Bien se demander quel objet est responsable de quoi.
• append(s) -> s.append()