Refactorisation
* Le processus de modification du code de telle sorte que
le comportement externe reste inchangé
l‘architecture interne soit améliorée
* Nomenclature, formatage, fonction, commentaires superflus, etc.
Agilité et Refactorisation
- Cascade : Vision traditionnelle
- une conception intégrale, ensuite le développement
- Cependant, avec le temps le code va sentir mauvais.
* L’intégrité du système va progressivement disparaître
* par rapport à la conception originale du système. Le code passe d’une
approche « génie logiciel » à une approche bidouillage/bricolage - « hacking »
- Agilité : Refactorisation.
- Changer progressivement le code pour obtenir une conception saine
- la conception s’améliore continuellement en fonction des itérations de
développement
* En développant l’application, on trouve les moyens d’améliorer la conception.
Quand refactoriser
* Refactorisation fait partie prenante du cycle de développement
- Maintenir le code lisible et modifiable
* Le code est lu et modifié plus souvent qu’il n’est écrit. - la suppression du code redondant ou inutile
- L’optimisation de la hiérarchie des classes
Raisons pour
refactoriser
Code mal placé
Objets mal nommés
Duplication de code
Conception non orthogonale
Meilleure connaissances du problème
Multiple nivaux d’agrégation
Multiple responsabilité
Performance
Processus de refactorisation
* Difficile et risqué
- Faire des changements dans un code fonctionnel
* Introduction éventuelle de nouvelles erreurs dans le code. - Mauvaise refactorisation ou faite de manière non structurée,
* Retour en arrière du projet de plusieurs semaines, et même de plusieurs mois.
Processus de refactorisation
* Minimiser les risques
- Préalablement à n’importe quelle refactorisation, il faut avoir une bonne suite de
tests
* Ces tests doivent avoir une couverture optimale du code.
* Ces tests doivent pouvoir être lancés automatiquement.
Processus de refactorisation
* Refactorisation.
*souvent les changements diminuent légèrement la performance du système
* Cependant, le système est plus facile à maintenir
* Code plus facile à comprendre,
* Code plus facile à modifier
* Pour la plupart des systèmes, la diminution de la performance minimale (petite fraction du code) ou non perceptible (quelques millisecondes)
- Gain de temps et de budget pour maintenir
- Ajout plus rapide de fonctionnalités
- Granularité plus fine pour les fonctions
- Fonctions plus petites à modifier
Catalogue de techniques de refactorisation
- Composition de méthodes
* « Extract Method »
* « Split with Temporary Variable »
* « Replace Temp with Query » - Déplacement de « propriétés » entre les objets
* « Move Method » - Organisation des données
* « Self Encapsulate Field »
* « Replace Type Code with State/Strategy » - Simplification des expressions conditionnelles
* « Replace Conditional with Polymorphism » - Simplification des invocations de méthodes
- Gestion de la généralisation
* « Form Template Method »
Conclusion
- Code plus facile à maintenir et à modifier
- S’il y a des changements au niveau
* de la structure des classes,
* des règles d’affaires
- S’il y a des changements au niveau
- Toutes les modifications doivent mèner
- à une meilleure distribution des responsabilités (Principe de la responsabilité unique)
- du code plus facile à maintenir
- Rythme de la refactorisation
- Petite modification, test, petite modification, test…
- Les IDE modernes fournissent des fonctionnalités de refactoring automatiques
- Renommer des objets, des variables, etc.
