dans Programmation 101
Le guide du développeur scout
Un échéancier serré, un budget serré, un manque de connaissances techniques au niveau de l’équipe, une mauvaise décision architecturale, la rotation de personnel sur plusieurs années et bien d’autres réalités sont des sources potentielles de légacification (oui oui! j’invente des mots).
Application Legacy
Lorsque le coût pour développer une amélioration à l’application est plus grand que le bénéfice encouru.
Aujourd’hui, je vous présente un petit guide pour développeurs pour minimiser au maximum les risques que l’application devienne legacy par votre faute.
La règle du boy scout
Tout comme les scouts lorsqu’ils sont en forêt, un développeur ne doit pas passer à côté d’une cochonnerie qui traîne sans la ramasser. Il faut laisser le code dans un état plus propre qu’il ne l’était avant notre passage.
MAIS!
N’allez pas modifier de code sans filet de sécurité. Si vous faites des régressions en le modifiant, vous ne serez pas plus avancés…
Le refactoring
Lorsqu’on parle de refactoring ou réingénierie, cela signifie que le code produit doit faire EXACTEMENT la même chose, mais :
- plus rapidement; et/ou
- plus simplement; et/ou
- plus proprement.
Pour ce faire, le processus requiert une analyse préliminaire.
Quantifier les risques de régression
Cette étape est la plus importante. Elle vous permettra de décider si vous procédez avec la réingénierie ou non. En supposant que vous travaillez avec un langage fortement typé et compilé, vous pouvez par exemple trouver les appelants d’une méthode pour déterminer les impacts, puis les appelants des appelants et ainsi de suite… ou la supprimer et compiler!
Sachez simplement que, peu importe la nature du code à changer, le risque n’est jamais nul.
Installer un filet de sécurité
Avant de toucher au code, trouver une stratégie pour rendre testable la classe à modifier. Il existe plusieurs façons de faire dépendamment de la source du problème et du niveau couplage entre les objets.
Pour qu’elle soit facilement testable en elle même, vous devez au minimum instancier ou mocker ses dépendances. Il sera alors possible d’appeler la méthode qu’il faut refactoriser via une suite de tests.
Dépendamment de la complexité de la méthode et de la classe, cette tâche peut être ardue. Par contre, si vous êtes conscients des risques, il y a aussi des funabules sans filet. Il vous restera toujours l’option d’annuler vos changements dans le système de versionnage 😉
Puis, une fois que la méthode est appellable via une suite de tests, vous pouvez commencer les travaux.
Utiliser des méthodes reconnues
Voici quelques exemples de techniques qui sont faciles à utiliser dans la plupart des environnements de développement intégrés. Faites une recherche Google et apprenez les raccourcis clavier!
1. Extraire une méthode (Extract Method)
Une méthode qui contient plus 20 lignes avec blocs de code visuellement séparés par des sauts de ligne ou des commentaires.
Solution
Créer une nouvelle méthode pour chaque bouts isolables.
2. Extraire une variable (Extract Variable)
Certains blocs de code sont compliqués ou sont écrits sur une seule ligne.
Solution
Créer des variables temporaires pour améliorer la lisibilité et extraire les blocs communs dans des méthodes.
3. Extraire une classe parente (Extract Superclass)
Plusieurs classes partagent un comportement commun, ou une partie de leurs membres sont semblables.
Solution
Extraire le code commun dans une classe parente.
4. Extraire l’interface (Extract Interface)
Vous avez une classe qui garde une instance d’une autre sans passer par une couche d’abstraction et vous voulez diminuer le couplage entre elles.
Solution
Créer une interface pour la classe et ajouter les signatures de toutes les méthodes publiques. Utilisez ensuite l’interface au lieu de la classe concrète.
5. Extraire une classe (Extract Class)
Après avoir refactorisé les méthodes, la classe devient chargée. Plusieurs paramètres identiques se retrouvent dans la signature de plusieurs méthodes qui partagent un concept commun. Souvent, vous remarquerez que ces méthodes sont visuellement groupées dans la classe.
Solution
Extraire les méthodes communes dans des classes séparées en gardant en tête le principe de responsabilité unique. Pour éviter le couplage, appliquer aussi le #4 et l’injection de dépendances!
Et ensuite?
Martin Fowler a inspiré plusieurs développeurs à jouer au chirurgien avec du vieux code. Apprendre à apprécier le code legacy lorsqu’on vit dans un monde qui évolue aussi vite, c’est aussi exigent que de suivre la vague. Son livre Working Effectively with Legacy Code peut être une suite intéressante si vous avez à travailler avec des applications désuètes, mais qui tournent encore en production!
Vous avez aimé? Partagez 🙂
Commentaires
Laisser un commentaire