Refactoring code

Questions à se poser pour déterminer quand refactoriser et quoi refactoriser

• Qu’est-ce qui apporte de la valeur à nos utilisateurs ?
• Qu’est-ce qui change fréquemment ?
• Quel est le besoin ?
• Retour sur investissement (ROI)
• Réduire le temps de mise en production
• Ne pas refactoriser en sous-marin, avoir l’accord de sa hiérarchie

Comment s’y prendre

• Mise en place de CI/CD
• Mise en place de tests automatisés pour s’assurer que le comportement reste le même
• Faire par petite touche (petit commit, une ligne, une seule modification)
• Tests sur la partie la plus critique (par exemple le système de payements)
• Détection des Code Smell (Primitive obsession à remplacer par des objects, if imbriqués)
• Kata (exercices pour apprendre à bien coder)
• TDD (Test-Driven Development) dév piloté par les tests
• BDD (Behavior-Driven Development) dév piloté par le comportement
• Corriger les lazy class
• Méthode du golden master, utiliser des jeux de données en entrée et vérifier qu’en sortie on a toujours bien ce que l’on attend
• Méthode du coverage, s’assurer que nos tests couvrent tous les cas possibles