SlideShare une entreprise Scribd logo
1  sur  53
Télécharger pour lire hors ligne
Tester du Legacy Code,
mission impossible ?
Bon après-midi, Ethan.
• Votre mission, si vous l’acceptez, consiste à vous
occuper d’un système informatique qui n’est pas
nouveau ni trop vieux, mais qui n’a aucun tests
automatisé.
• Par contre, il est au cœur de plusieurs traitements
d’affaires critiques. Vous allez avoir à ajouter de
nouvelles fonctionnalités et a en faire l’entretien.
• Nous avons observés les choses suivantes:
– Classes de la logique d’affaire qui fait 32 000 lignes.
– Une interface de 2000 lignes (incluant une ligne de
commentaire par méthode) été créé récemment pour vous
permettre d’introduire des tests.
• Ce message s’auto-détruira dans 5 secondes …..
Bon après-midi, Ethan.
• Votre mission, si vous l’acceptez, consiste à vous
occuper d’un système informatique qui n’est pas
nouveau ni trop vieux, mais qui n’a aucun tests
automatisé.
• Par contre, il est au cœur de plusieurs traitements
d’affaires critiques. Vous allez avoir à ajouter de
nouvelles fonctionnalités et a en faire l’entretien.
• Nous avons observés les choses suivantes:
– Classes de la logique d’affaire qui fait 32 000 lignes.
– Une interface de 2000 lignes (incluant une ligne de
commentaire par méthode) été créé récemment pour vous
permettre d’introduire des tests.
• Ce message s’auto-détruira dans 5 secondes …..
MISSION
Qui sommes-nous ?
• Karl Métivier
– Architecte Logiciel
– Développeur
– Coach Agile
– Formateur
• Yves St-Hilaire
– Soutien au développement
– Accompagnement, mentorat
– Développement BI
Histoire d’un système
• On change notre processus, on passe
à Scrum.
• On nous demande d’ajouter des tests
unitaires automatisés au code
existant.
– Oups, le système n’a pas été prévu
pour cela…
• Comment avoir le temps pour cela ?
– Réunion pour discuter des bogues
courants.
– Documentation à mettre à jour.
• Au final, problème de dette
technique.
Code Legacy
C’est quoi pour vous ?
Définitions pour le Legacy Code
• Du code Legacy, c’est du code:
– sans tests unitaires - Michael Feathers
– plus vieux que ceux qui y travaillent
– modifications en mode « patchage »
– nécessitant un guide du marais pour
s’y retrouver!
• Enfreint constamment les principes
SOLID
• On n’ose pas y toucher.
• Et les Legacy Systems ?
Code « Legacy »
Quand vous avez à
travailler avec ça, c’est
quoi votre feeling ?
Pourquoi est-on pognés avec ça ?
• Délais courts de développement
• Plusieurs personnes y sont passées
• Conception Legacy?
–Architecture identique au dossier fonctionnel
• Peu d’efforts alloués pour l’amélioration
–Le système fonctionne, on n’y investit rien
Quel est le problème au juste ?
Architecture incohérente
La conception n’est pas conçue pour les tests
Dépendances cachées
Code «pas propre» et bien d’autres
Le dilemme du refactoring
• Pour faire du
refactoring, on doit
avoir des tests
• Pour mettre en place
des tests, on doit
refactoriser.
Tester le Legacy Code:
1 - Comment le faire ?
Cas 1 – Classe sans injection de dépendances
• Pas de possibilité d’injecter un mock
• Plusieurs appelants l’utilisent, souvent on ne
peut les modifier
Cas 1 – Classe sans injection de dépendances
Comment ?
• Pour la classe qu’on veut mocker :
– Ajout d’une interface
• À la classe à tester :
– Ajout d’un constructeur permettant l’injection
– On lui injectera l’instance à utiliser, ou une Factory
• Les appelants ne sont pas impactés
• On permet l’injection, mais les appelants existants
ne l’utilisent pas
Cas 1 – Ajout d’injection – Comment
public class MyClass {
private IFileReader reader;
public MyClass(string fileName) {
// original code
// ...
reader = new MyFileReader(fileName);
}
public MyClass(IFileReader injectedReader) {
// original code
// ...
reader = injectedReader;
}
}
Cas 1b – Classe sans injection de dépendances
Comment ?
• Autre technique : Patron « Test Specific Subclass »
• Classe à mocker : ajout d’une interface à la classe
• Classe à tester :
– Ajout d’une méthode virtuelle
« ObtenirInstanceClasseAppelee »
• Dans le projet de test :
– Hériter de la classe à tester
– Implémenter notre propre
« ObtenirInstanceClasseAppelee »
Cas 1b – Test specific subclass – Comment?
public class MyClass {
protected int someProtectedInfo = 42;
private IFileReader reader;
public MyClass(string fileName) {
reader = GetReader(fileName);
}
protected virtual IFileReader GetReader(string fileName) {
return new MyFileReader(fileName);
}}
public class MyClassSpecificSubclass : MyClass {
public IFileReader InsertMockHere;
public MyClassSpecificSubclass(IFileReader aReader) {
InsertMockHere = aReader;
}
protected override IFileReader GetReader(string fileName) {
return InsertMockHere;
}
public int GetInternalInfo() {
return someProtectedInfo;
}}
Cas 2 – La classe iceberg
• Reconnaissable facilement
– Grosse
• Milliers, dizaines de milliers de lignes
– Peu de méthodes publiques
• Comptées sur une seule main
• C’est quoi le problème?
– Grande complexité cyclomatique
– Interdépendances entre les méthodes
– Donc difficile à tester
Cas 2– La classe iceberg – Comment?
• Identifier les différentes responsabilités
– Noms de méthodes
– #Region ou zones de commentaires
• Refactoriser en plusieurs classes
• Si impossible :
– Identifiez les méthodes qui seraient publiques avec un
refactoring
– Changer la visibilité et testez ces méthodes
Cas 2– La classe iceberg – Exemple (classe
simplifiée!)
Cas 3 – Méthode statique
• Une méthode statique, l’équivalent d’un
singleton
• Une seule version possible pour tout le système
– Donc pas mockable
• Pas un problème pour la tester
• Mais un véritable problème pour tester les
méthodes qui l’appellent
Cas 3 – Méthode statique – Comment?
• Ajout d’une interface à la classe
• Ajout de méthodes d’instance
correspondant aux méthodes statiques
– DRY : la méthode d’instance peut
appeler la méthode statique!
– Les appelants ne sont pas affectés
• Éventuellement on pourra enlever
complètement les méthodes statiques
Cas 3 – Méthode statique – Code
public class ClassUnderTest
{
public void MethodUnderTest()
{
// ...
var number = AnotherClass.GetNumber();
if (number > 0)
{ }
else
{ }
// ...
}
}
public class AnotherClass
{
public static int GetNumber()
{
return 4;
}
}
Cas 3 – Méthode statique – Code
public class ClassUnderTest {
private IAnotherClass _anotherClass;
public ClassUnderTest() { _anotherClass = new AnotherClass(); }
public ClassUnderTest(IAnotherClass anotherClass) { _anotherClass = anotherClass; }
public void MethodUnderTest() {
// ...
var number = _anotherClass.GetNumber();
if (number > 0)
{ }
else
{ }
// ...
}
}
public class AnotherClass: IAnotherClass {
public static int GetNumber() { return 4; }
int IAnotherClass.GetNumber() {
return AnotherClass.GetNumber();
}
}
Mais en avez-vous vraiment besoin ?
• Parfois, l’ajout de tests unitaires
demande beaucoup d’efforts
pour peu de gains
• Évaluer d’autres opportunités
– CodedUI / Selenium
– Tests intégrés, mocker
uniquement les données
– Tests comparatifs
• Pas toujours les meilleures
pratiques, mais faut s’adapter au
contexte!
Comment le BDD m'a aidé dans mon débogage
• Partir d’un cas d’utilisation (déjà
implémenté) et le descendre en étape BDD
du début (contrôleur UI), passer par le
service et aboutir dans une BD en mémoire
• C’est long
• On vérifie toutes les dépendances et on
traverse toutes les couches
• C’est long, mais après coup notre
compréhension du code s’est vraiment
améliorée
• En plus, le test BDD reste et peut être
rejoué !
État d’esprit pour déboguer de Legacy Code
• Voir le code comme une scène de
crime
• Faire un profil de l’agresseur (ou de
ce qui cause le problème)
• Analyser les hot-spots
• Calculer la complexité
• Faire la dissection de l’architecture
• Cartographier une carte de
connaissances de votre système
• Impact sur l’existant
Tester le Legacy Code:
2 - Comment avoir le droit ?
Versus la résistance
C’est impossible d’en faire chez nous car…
• Nous autres, c'est différent
• On a un système de mission
critique à l'entreprise
• Nos utilisateurs ont le contrôle et
le budget
• Notre système est très complexe
• On a des données nominatives
• …
C’est notre devoir d’être professionnel
Du code propre n’apparaît
pas de lui-même:
• Vous avez à le produire
• Vous avez à le maintenir
• Vous en faites un
engagement professionnel
Combattre le résistance en discutant
• La plupart des gestionnaires
défendent leurs échéanciers et les
requis avec passion.
– Cela fait partie de leurs responsabilités.
• Votre responsabilité :
– Défendre également le code avec
passion.
• Ayez le courage de dire la vérité et
de travailler pour arriver à un terrain
d’entente.
• Discuter avec votre PO ou votre chef
d’équipe. Il devrait être sensible à la
qualité produite. Donc de supporter
l’équipe quand il sent qu’un
refactoring est nécessaire.
Il faut alors être stratégique
• Cela ne donne pas grand chose de
travailler sur du code qui va bien et qui
n’a pas de problème régulièrement.
Don’t fix it, if it’s not broken.
• Trouver les points chauds de votre
système:
– Bogues réguliers
– Difficiles à travailler
– Modification à faire prochainement
– Logique d’affaires importante
• Progresser par la technique des
petits pas.
Bien évaluer
Valeur de cet investissement :
• Potentiel
• Bloquant actuel
• Criticité du système
• Nombre de personnes impactées
• Durée de vie du système
• Refonte prévue?
La résistance peut donc être combattue
• C’est souvent le premier pas le
plus difficile.
• Ne pas oublier :
– Être stratégique
– Évaluer le tout
• Y aller un test à la fois:
– Et son Refactoring de code
qui le suit.
En fait, on en revient à la transparence
Le premier pilier de l’agilité!
3. Comment tester du
Legacy Code au jour le jour
et s’en prémunir?
Comprendre le code
• Les tests nous apportent une façon de
comprendre le code.
• D’une certaine manière, les tests nous
font travailler dur pour arriver à cette
compréhension.
• Il est facile de faire des tests en
présence d’une bonne conception.
Ne pas hésiter à utiliser des outils modernes
• Legacy != outils désuets
• Exemples :
– Intégration continue
– Dernière version de l’IDE
– Dernières versions des
librairies et frameworks
– Système Legacy dans Docker
Ne pas oublier les bases
• OOP
• Clean Code
• Maîtrisez et appliquez les
principes SOLID
• Boy Scout Rule
• Agile Modeling (Scott Ambler)
Se prémunir contre le Legacy Code à la base
• Les développeurs doivent
demander Quoi, Pourquoi et
pour Qui avant de trouver le
Comment.
• Ce n’est pas aux analystes et
utilisateurs de leur dire le
Comment.
• On veut savoir du client/PO
qu’est-ce qu’ils veulent,
pourquoi ils le veulent et pour
qui cela va être utile.
Faire la conception en équipe
• Les meilleures conceptions sont
effectuées en équipe, et non par
une seule personne.
• La compréhension de
l’architecture ainsi que son
adoption est répandue dans toute
l’équipe.
• Pourquoi s’en passer ?
Ou du Mob Programming !
• Approche où l’équipe
complète (client, analyste
et PO aussi) travaille sur la
même chose :
– Au même endroit
– En même temps
– Sur le même ordinateur
• Un peu similaire au pair
programming
En résumé, nous avons vu…
• C’est quoi du Legacy Code
• Comment faire pour le tester
• Comment affronter la résistance
• Comment s’en prémunir au jour le jour
Alors, tester du du Legacy Code,
• Met à l’épreuve et renforce nos
habilités en:
– Programmation Orientée-Objet
– Conception & Architecture
• Offre un challenge qui peut donc
être instructif et amusant !
• Nous rend plus professionnel en bout
de ligne.
Comment vous en sortez-vous avec le Legacy Code ?
Références 1/2
• Podcast Hanselminutes 2016-08-05 « Learning to love Legacy Code
with Andrea Goulet from CorgiByte »
– http://hanselminutes.com/539/learning-to-love-legacy-code-
with-andrea-goulet-from-corgibytes
• Patron « Test Specific Subclass »
– http://xunitpatterns.com/Test-Specific%20Subclass.html
• XKCD Goto
– https://xkcd.com/292/
Autres références
• Lectures suggérées
• Beaucoup de
connaissances et
d’information sur le
‘net
Pour nous rejoindre
• Karl Métivier
– Courriel: kmetivier@facilite.com
– LinkedIn: https://www.linkedin.com/in/karlmetivier/fr
– Twitter: @karlmet
– Blogue: https://excellenceagile.com/
• Yves St-Hilaire
– Courriel: yves.sthilaire@gmail.com
– LinkedIn: www.linkedin.com/in/yves-st-hilaire
– Twitter: @sthiy

Contenu connexe

Tendances

Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionTremeur Balbous
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmseagnes_crepet
 
How to fail at benchmarking?
How to fail at benchmarking?How to fail at benchmarking?
How to fail at benchmarking?Pierre Laporte
 
Contractualisation agile : Saison 2 (atm)
Contractualisation agile :  Saison 2 (atm)Contractualisation agile :  Saison 2 (atm)
Contractualisation agile : Saison 2 (atm)Michel Lejeune
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsPierre E. NEIS
 
Présentation de l’agilité
Présentation de l’agilitéPrésentation de l’agilité
Présentation de l’agilitéJean Yves Klein
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileLaurent Deséchalliers
 
Introduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jourIntroduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jourRenaud BROSSE
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agilelaurent bristiel
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slidesNicolas Deverge
 
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?Publicis Sapient Engineering
 
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)Couthaïer FARFRA
 
Agile - DevOps : la boite à outils
Agile - DevOps : la boite à outilsAgile - DevOps : la boite à outils
Agile - DevOps : la boite à outilsFrantz Degrigny
 
Lean Kanban Une Inversion de Controle
Lean Kanban Une Inversion de ControleLean Kanban Une Inversion de Controle
Lean Kanban Une Inversion de ControleDimitri Baeli
 
Agilité à budget fixe en phase d'avant-vente. Que proposer ?
Agilité à budget fixe en phase d'avant-vente. Que proposer ?Agilité à budget fixe en phase d'avant-vente. Que proposer ?
Agilité à budget fixe en phase d'avant-vente. Que proposer ?Frantz Degrigny
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVPierre
 

Tendances (20)

Large Scale Scrum
Large Scale ScrumLarge Scale Scrum
Large Scale Scrum
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmse
 
How to fail at benchmarking?
How to fail at benchmarking?How to fail at benchmarking?
How to fail at benchmarking?
 
Contractualisation agile : Saison 2 (atm)
Contractualisation agile :  Saison 2 (atm)Contractualisation agile :  Saison 2 (atm)
Contractualisation agile : Saison 2 (atm)
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
 
Lunch learn 5 sep2013
Lunch learn 5 sep2013Lunch learn 5 sep2013
Lunch learn 5 sep2013
 
Agile presentation
Agile presentationAgile presentation
Agile presentation
 
Présentation de l’agilité
Présentation de l’agilitéPrésentation de l’agilité
Présentation de l’agilité
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agile
 
Introduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jourIntroduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jour
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agile
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slides
 
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
 
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
 
Agile - DevOps : la boite à outils
Agile - DevOps : la boite à outilsAgile - DevOps : la boite à outils
Agile - DevOps : la boite à outils
 
Lean Kanban Une Inversion de Controle
Lean Kanban Une Inversion de ControleLean Kanban Une Inversion de Controle
Lean Kanban Une Inversion de Controle
 
Agilité à budget fixe en phase d'avant-vente. Que proposer ?
Agilité à budget fixe en phase d'avant-vente. Que proposer ?Agilité à budget fixe en phase d'avant-vente. Que proposer ?
Agilité à budget fixe en phase d'avant-vente. Que proposer ?
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
 

En vedette

Passez un test de la vue - Outils visuels pour y voir clair!
Passez un test de la vue - Outils visuels pour y voir clair!Passez un test de la vue - Outils visuels pour y voir clair!
Passez un test de la vue - Outils visuels pour y voir clair!CGI Québec Formation
 
Catalyser votre transition agile avec le codéveloppement
Catalyser votre transition agile avec le codéveloppementCatalyser votre transition agile avec le codéveloppement
Catalyser votre transition agile avec le codéveloppementCGI Québec Formation
 
Why certain code is hard to test?
Why certain code is hard to test?Why certain code is hard to test?
Why certain code is hard to test?Kosala Nuwan Perera
 
Martin folwer
Martin folwerMartin folwer
Martin folwerShiraz316
 
Software Design Patterns
Software Design PatternsSoftware Design Patterns
Software Design PatternsCode Gentlemen
 
Estimation initiale dun projet agile de Mathieu Boisvert
Estimation initiale dun projet agile de Mathieu BoisvertEstimation initiale dun projet agile de Mathieu Boisvert
Estimation initiale dun projet agile de Mathieu BoisvertPyxis Technologies
 
La co-création, ou comment innover avec le client?
La co-création, ou comment innover avec le client?La co-création, ou comment innover avec le client?
La co-création, ou comment innover avec le client?Robert Viseur
 
Ctifl Reperes Semo Cocreation Fruit Et LéGumes Def
Ctifl Reperes Semo   Cocreation Fruit Et LéGumes DefCtifl Reperes Semo   Cocreation Fruit Et LéGumes Def
Ctifl Reperes Semo Cocreation Fruit Et LéGumes DefFrançois Abiven
 
Du JavaScript propre ? Challenge accepted ! @Devoxx France 2013
Du JavaScript propre ? Challenge accepted ! @Devoxx France 2013Du JavaScript propre ? Challenge accepted ! @Devoxx France 2013
Du JavaScript propre ? Challenge accepted ! @Devoxx France 2013Julien Jakubowski
 

En vedette (13)

Passez un test de la vue - Outils visuels pour y voir clair!
Passez un test de la vue - Outils visuels pour y voir clair!Passez un test de la vue - Outils visuels pour y voir clair!
Passez un test de la vue - Outils visuels pour y voir clair!
 
Catalyser votre transition agile avec le codéveloppement
Catalyser votre transition agile avec le codéveloppementCatalyser votre transition agile avec le codéveloppement
Catalyser votre transition agile avec le codéveloppement
 
Rétrospectives en 4 actes
Rétrospectives en 4 actesRétrospectives en 4 actes
Rétrospectives en 4 actes
 
Why certain code is hard to test?
Why certain code is hard to test?Why certain code is hard to test?
Why certain code is hard to test?
 
Java annotation
Java annotationJava annotation
Java annotation
 
Martin folwer
Martin folwerMartin folwer
Martin folwer
 
Software Design Patterns
Software Design PatternsSoftware Design Patterns
Software Design Patterns
 
Estimation initiale dun projet agile de Mathieu Boisvert
Estimation initiale dun projet agile de Mathieu BoisvertEstimation initiale dun projet agile de Mathieu Boisvert
Estimation initiale dun projet agile de Mathieu Boisvert
 
La co-création, ou comment innover avec le client?
La co-création, ou comment innover avec le client?La co-création, ou comment innover avec le client?
La co-création, ou comment innover avec le client?
 
Symfony Best Practices
Symfony Best PracticesSymfony Best Practices
Symfony Best Practices
 
Ctifl Reperes Semo Cocreation Fruit Et LéGumes Def
Ctifl Reperes Semo   Cocreation Fruit Et LéGumes DefCtifl Reperes Semo   Cocreation Fruit Et LéGumes Def
Ctifl Reperes Semo Cocreation Fruit Et LéGumes Def
 
Du JavaScript propre ? Challenge accepted ! @Devoxx France 2013
Du JavaScript propre ? Challenge accepted ! @Devoxx France 2013Du JavaScript propre ? Challenge accepted ! @Devoxx France 2013
Du JavaScript propre ? Challenge accepted ! @Devoxx France 2013
 
4D Summit2013 refactoring
4D Summit2013 refactoring4D Summit2013 refactoring
4D Summit2013 refactoring
 

Similaire à Tester du legacy code, mission impossible ?

Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgileAgile Tour 2009 Québec
 
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Xavier NOPRE
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyonClement Bouillier
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2Christophe Rochefolle
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testablemartinsson
 
C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?Rémi Lesieur
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringneuros
 
Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Elapse Technologies
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingGeeks Anonymes
 
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAgile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsThierry Gayet
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésDjamel Zouaoui
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)French Scrum User Group
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logicielsSylvain Leroy
 
Toutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBToutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBContent Square
 
Pourquoi vous ne pouvez pas tester votre code
Pourquoi vous ne pouvez pas tester votre codePourquoi vous ne pouvez pas tester votre code
Pourquoi vous ne pouvez pas tester votre codeRémi Lesieur
 
La revue de code : facile !
La revue de code : facile !La revue de code : facile !
La revue de code : facile !Lucian Precup
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsAgile Tour 2009 Québec
 

Similaire à Tester du legacy code, mission impossible ? (20)

Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
 
Usine Logicielle 2013
Usine Logicielle 2013Usine Logicielle 2013
Usine Logicielle 2013
 
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
 
Tour d'horizon des tests
Tour d'horizon des testsTour d'horizon des tests
Tour d'horizon des tests
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
 
C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
 
Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
 
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAgile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testable
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisés
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logiciels
 
Toutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBToutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDB
 
Pourquoi vous ne pouvez pas tester votre code
Pourquoi vous ne pouvez pas tester votre codePourquoi vous ne pouvez pas tester votre code
Pourquoi vous ne pouvez pas tester votre code
 
La revue de code : facile !
La revue de code : facile !La revue de code : facile !
La revue de code : facile !
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
 

Plus de CGI Québec Formation

La culture produit au service du client
La culture produit au service du clientLa culture produit au service du client
La culture produit au service du clientCGI Québec Formation
 
Gestion de performance : L'agilité à l'échelle
Gestion de performance : L'agilité à l'échelleGestion de performance : L'agilité à l'échelle
Gestion de performance : L'agilité à l'échelleCGI Québec Formation
 
La 5e Valeur Agile: La valeur plutôt que le suivi des coûts
La 5e Valeur Agile: La valeur plutôt que le suivi des coûtsLa 5e Valeur Agile: La valeur plutôt que le suivi des coûts
La 5e Valeur Agile: La valeur plutôt que le suivi des coûtsCGI Québec Formation
 
Démarrage express. Vers des démarrages de projets plus rapides et moins couteux
Démarrage express. Vers des démarrages de projets plus rapides et moins couteuxDémarrage express. Vers des démarrages de projets plus rapides et moins couteux
Démarrage express. Vers des démarrages de projets plus rapides et moins couteuxCGI Québec Formation
 
Estimer les projets TI, même en Agile
Estimer les projets TI, même en AgileEstimer les projets TI, même en Agile
Estimer les projets TI, même en AgileCGI Québec Formation
 
Large Scale Agile Transformation in Government: Field report
Large Scale Agile Transformation in Government: Field reportLarge Scale Agile Transformation in Government: Field report
Large Scale Agile Transformation in Government: Field reportCGI Québec Formation
 
Gestion de portefeuille performante et kanban stratégique - Version courte
Gestion de portefeuille performante et kanban stratégique - Version courteGestion de portefeuille performante et kanban stratégique - Version courte
Gestion de portefeuille performante et kanban stratégique - Version courteCGI Québec Formation
 
Strategic Portfolio Management With Kanban
Strategic Portfolio Management With KanbanStrategic Portfolio Management With Kanban
Strategic Portfolio Management With KanbanCGI Québec Formation
 
Quelles sont vos attentes envers les ScrumMasters
Quelles sont vos attentes envers les ScrumMastersQuelles sont vos attentes envers les ScrumMasters
Quelles sont vos attentes envers les ScrumMastersCGI Québec Formation
 
Semer la graine agile en entretien et évolution de systèmes
Semer la graine agile en entretien et évolution de systèmesSemer la graine agile en entretien et évolution de systèmes
Semer la graine agile en entretien et évolution de systèmesCGI Québec Formation
 
Les bases de données, ces mal-aimées de l'Agilité!
Les bases de données, ces mal-aimées de l'Agilité!Les bases de données, ces mal-aimées de l'Agilité!
Les bases de données, ces mal-aimées de l'Agilité!CGI Québec Formation
 
Mon Agilité est plus grosse que la tienne
Mon Agilité est plus grosse que la tienneMon Agilité est plus grosse que la tienne
Mon Agilité est plus grosse que la tienneCGI Québec Formation
 

Plus de CGI Québec Formation (14)

La culture produit au service du client
La culture produit au service du clientLa culture produit au service du client
La culture produit au service du client
 
Mythes et légendesKanban
Mythes et légendesKanbanMythes et légendesKanban
Mythes et légendesKanban
 
Gestion de performance : L'agilité à l'échelle
Gestion de performance : L'agilité à l'échelleGestion de performance : L'agilité à l'échelle
Gestion de performance : L'agilité à l'échelle
 
La 5e Valeur Agile: La valeur plutôt que le suivi des coûts
La 5e Valeur Agile: La valeur plutôt que le suivi des coûtsLa 5e Valeur Agile: La valeur plutôt que le suivi des coûts
La 5e Valeur Agile: La valeur plutôt que le suivi des coûts
 
Démarrage express. Vers des démarrages de projets plus rapides et moins couteux
Démarrage express. Vers des démarrages de projets plus rapides et moins couteuxDémarrage express. Vers des démarrages de projets plus rapides et moins couteux
Démarrage express. Vers des démarrages de projets plus rapides et moins couteux
 
Estimer les projets TI, même en Agile
Estimer les projets TI, même en AgileEstimer les projets TI, même en Agile
Estimer les projets TI, même en Agile
 
Large Scale Agile Transformation in Government: Field report
Large Scale Agile Transformation in Government: Field reportLarge Scale Agile Transformation in Government: Field report
Large Scale Agile Transformation in Government: Field report
 
Atelier de simulation DevOps
Atelier de simulation DevOpsAtelier de simulation DevOps
Atelier de simulation DevOps
 
Gestion de portefeuille performante et kanban stratégique - Version courte
Gestion de portefeuille performante et kanban stratégique - Version courteGestion de portefeuille performante et kanban stratégique - Version courte
Gestion de portefeuille performante et kanban stratégique - Version courte
 
Strategic Portfolio Management With Kanban
Strategic Portfolio Management With KanbanStrategic Portfolio Management With Kanban
Strategic Portfolio Management With Kanban
 
Quelles sont vos attentes envers les ScrumMasters
Quelles sont vos attentes envers les ScrumMastersQuelles sont vos attentes envers les ScrumMasters
Quelles sont vos attentes envers les ScrumMasters
 
Semer la graine agile en entretien et évolution de systèmes
Semer la graine agile en entretien et évolution de systèmesSemer la graine agile en entretien et évolution de systèmes
Semer la graine agile en entretien et évolution de systèmes
 
Les bases de données, ces mal-aimées de l'Agilité!
Les bases de données, ces mal-aimées de l'Agilité!Les bases de données, ces mal-aimées de l'Agilité!
Les bases de données, ces mal-aimées de l'Agilité!
 
Mon Agilité est plus grosse que la tienne
Mon Agilité est plus grosse que la tienneMon Agilité est plus grosse que la tienne
Mon Agilité est plus grosse que la tienne
 

Tester du legacy code, mission impossible ?

  • 1. Tester du Legacy Code, mission impossible ?
  • 2. Bon après-midi, Ethan. • Votre mission, si vous l’acceptez, consiste à vous occuper d’un système informatique qui n’est pas nouveau ni trop vieux, mais qui n’a aucun tests automatisé. • Par contre, il est au cœur de plusieurs traitements d’affaires critiques. Vous allez avoir à ajouter de nouvelles fonctionnalités et a en faire l’entretien. • Nous avons observés les choses suivantes: – Classes de la logique d’affaire qui fait 32 000 lignes. – Une interface de 2000 lignes (incluant une ligne de commentaire par méthode) été créé récemment pour vous permettre d’introduire des tests. • Ce message s’auto-détruira dans 5 secondes …..
  • 3. Bon après-midi, Ethan. • Votre mission, si vous l’acceptez, consiste à vous occuper d’un système informatique qui n’est pas nouveau ni trop vieux, mais qui n’a aucun tests automatisé. • Par contre, il est au cœur de plusieurs traitements d’affaires critiques. Vous allez avoir à ajouter de nouvelles fonctionnalités et a en faire l’entretien. • Nous avons observés les choses suivantes: – Classes de la logique d’affaire qui fait 32 000 lignes. – Une interface de 2000 lignes (incluant une ligne de commentaire par méthode) été créé récemment pour vous permettre d’introduire des tests. • Ce message s’auto-détruira dans 5 secondes ….. MISSION
  • 4. Qui sommes-nous ? • Karl Métivier – Architecte Logiciel – Développeur – Coach Agile – Formateur • Yves St-Hilaire – Soutien au développement – Accompagnement, mentorat – Développement BI
  • 5. Histoire d’un système • On change notre processus, on passe à Scrum. • On nous demande d’ajouter des tests unitaires automatisés au code existant. – Oups, le système n’a pas été prévu pour cela… • Comment avoir le temps pour cela ? – Réunion pour discuter des bogues courants. – Documentation à mettre à jour. • Au final, problème de dette technique.
  • 7. Définitions pour le Legacy Code • Du code Legacy, c’est du code: – sans tests unitaires - Michael Feathers – plus vieux que ceux qui y travaillent – modifications en mode « patchage » – nécessitant un guide du marais pour s’y retrouver! • Enfreint constamment les principes SOLID • On n’ose pas y toucher. • Et les Legacy Systems ?
  • 8. Code « Legacy » Quand vous avez à travailler avec ça, c’est quoi votre feeling ?
  • 9. Pourquoi est-on pognés avec ça ? • Délais courts de développement • Plusieurs personnes y sont passées • Conception Legacy? –Architecture identique au dossier fonctionnel • Peu d’efforts alloués pour l’amélioration –Le système fonctionne, on n’y investit rien
  • 10. Quel est le problème au juste ?
  • 12. La conception n’est pas conçue pour les tests
  • 14. Code «pas propre» et bien d’autres
  • 15. Le dilemme du refactoring • Pour faire du refactoring, on doit avoir des tests • Pour mettre en place des tests, on doit refactoriser.
  • 16. Tester le Legacy Code: 1 - Comment le faire ?
  • 17. Cas 1 – Classe sans injection de dépendances • Pas de possibilité d’injecter un mock • Plusieurs appelants l’utilisent, souvent on ne peut les modifier
  • 18. Cas 1 – Classe sans injection de dépendances Comment ? • Pour la classe qu’on veut mocker : – Ajout d’une interface • À la classe à tester : – Ajout d’un constructeur permettant l’injection – On lui injectera l’instance à utiliser, ou une Factory • Les appelants ne sont pas impactés • On permet l’injection, mais les appelants existants ne l’utilisent pas
  • 19. Cas 1 – Ajout d’injection – Comment public class MyClass { private IFileReader reader; public MyClass(string fileName) { // original code // ... reader = new MyFileReader(fileName); } public MyClass(IFileReader injectedReader) { // original code // ... reader = injectedReader; } }
  • 20. Cas 1b – Classe sans injection de dépendances Comment ? • Autre technique : Patron « Test Specific Subclass » • Classe à mocker : ajout d’une interface à la classe • Classe à tester : – Ajout d’une méthode virtuelle « ObtenirInstanceClasseAppelee » • Dans le projet de test : – Hériter de la classe à tester – Implémenter notre propre « ObtenirInstanceClasseAppelee »
  • 21. Cas 1b – Test specific subclass – Comment? public class MyClass { protected int someProtectedInfo = 42; private IFileReader reader; public MyClass(string fileName) { reader = GetReader(fileName); } protected virtual IFileReader GetReader(string fileName) { return new MyFileReader(fileName); }} public class MyClassSpecificSubclass : MyClass { public IFileReader InsertMockHere; public MyClassSpecificSubclass(IFileReader aReader) { InsertMockHere = aReader; } protected override IFileReader GetReader(string fileName) { return InsertMockHere; } public int GetInternalInfo() { return someProtectedInfo; }}
  • 22. Cas 2 – La classe iceberg • Reconnaissable facilement – Grosse • Milliers, dizaines de milliers de lignes – Peu de méthodes publiques • Comptées sur une seule main • C’est quoi le problème? – Grande complexité cyclomatique – Interdépendances entre les méthodes – Donc difficile à tester
  • 23. Cas 2– La classe iceberg – Comment? • Identifier les différentes responsabilités – Noms de méthodes – #Region ou zones de commentaires • Refactoriser en plusieurs classes • Si impossible : – Identifiez les méthodes qui seraient publiques avec un refactoring – Changer la visibilité et testez ces méthodes
  • 24. Cas 2– La classe iceberg – Exemple (classe simplifiée!)
  • 25. Cas 3 – Méthode statique • Une méthode statique, l’équivalent d’un singleton • Une seule version possible pour tout le système – Donc pas mockable • Pas un problème pour la tester • Mais un véritable problème pour tester les méthodes qui l’appellent
  • 26. Cas 3 – Méthode statique – Comment? • Ajout d’une interface à la classe • Ajout de méthodes d’instance correspondant aux méthodes statiques – DRY : la méthode d’instance peut appeler la méthode statique! – Les appelants ne sont pas affectés • Éventuellement on pourra enlever complètement les méthodes statiques
  • 27. Cas 3 – Méthode statique – Code public class ClassUnderTest { public void MethodUnderTest() { // ... var number = AnotherClass.GetNumber(); if (number > 0) { } else { } // ... } } public class AnotherClass { public static int GetNumber() { return 4; } }
  • 28. Cas 3 – Méthode statique – Code public class ClassUnderTest { private IAnotherClass _anotherClass; public ClassUnderTest() { _anotherClass = new AnotherClass(); } public ClassUnderTest(IAnotherClass anotherClass) { _anotherClass = anotherClass; } public void MethodUnderTest() { // ... var number = _anotherClass.GetNumber(); if (number > 0) { } else { } // ... } } public class AnotherClass: IAnotherClass { public static int GetNumber() { return 4; } int IAnotherClass.GetNumber() { return AnotherClass.GetNumber(); } }
  • 29. Mais en avez-vous vraiment besoin ? • Parfois, l’ajout de tests unitaires demande beaucoup d’efforts pour peu de gains • Évaluer d’autres opportunités – CodedUI / Selenium – Tests intégrés, mocker uniquement les données – Tests comparatifs • Pas toujours les meilleures pratiques, mais faut s’adapter au contexte!
  • 30. Comment le BDD m'a aidé dans mon débogage • Partir d’un cas d’utilisation (déjà implémenté) et le descendre en étape BDD du début (contrôleur UI), passer par le service et aboutir dans une BD en mémoire • C’est long • On vérifie toutes les dépendances et on traverse toutes les couches • C’est long, mais après coup notre compréhension du code s’est vraiment améliorée • En plus, le test BDD reste et peut être rejoué !
  • 31. État d’esprit pour déboguer de Legacy Code • Voir le code comme une scène de crime • Faire un profil de l’agresseur (ou de ce qui cause le problème) • Analyser les hot-spots • Calculer la complexité • Faire la dissection de l’architecture • Cartographier une carte de connaissances de votre système • Impact sur l’existant
  • 32. Tester le Legacy Code: 2 - Comment avoir le droit ?
  • 34. C’est impossible d’en faire chez nous car… • Nous autres, c'est différent • On a un système de mission critique à l'entreprise • Nos utilisateurs ont le contrôle et le budget • Notre système est très complexe • On a des données nominatives • …
  • 35. C’est notre devoir d’être professionnel Du code propre n’apparaît pas de lui-même: • Vous avez à le produire • Vous avez à le maintenir • Vous en faites un engagement professionnel
  • 36. Combattre le résistance en discutant • La plupart des gestionnaires défendent leurs échéanciers et les requis avec passion. – Cela fait partie de leurs responsabilités. • Votre responsabilité : – Défendre également le code avec passion. • Ayez le courage de dire la vérité et de travailler pour arriver à un terrain d’entente. • Discuter avec votre PO ou votre chef d’équipe. Il devrait être sensible à la qualité produite. Donc de supporter l’équipe quand il sent qu’un refactoring est nécessaire.
  • 37. Il faut alors être stratégique • Cela ne donne pas grand chose de travailler sur du code qui va bien et qui n’a pas de problème régulièrement. Don’t fix it, if it’s not broken. • Trouver les points chauds de votre système: – Bogues réguliers – Difficiles à travailler – Modification à faire prochainement – Logique d’affaires importante • Progresser par la technique des petits pas.
  • 38. Bien évaluer Valeur de cet investissement : • Potentiel • Bloquant actuel • Criticité du système • Nombre de personnes impactées • Durée de vie du système • Refonte prévue?
  • 39. La résistance peut donc être combattue • C’est souvent le premier pas le plus difficile. • Ne pas oublier : – Être stratégique – Évaluer le tout • Y aller un test à la fois: – Et son Refactoring de code qui le suit.
  • 40. En fait, on en revient à la transparence Le premier pilier de l’agilité!
  • 41. 3. Comment tester du Legacy Code au jour le jour et s’en prémunir?
  • 42. Comprendre le code • Les tests nous apportent une façon de comprendre le code. • D’une certaine manière, les tests nous font travailler dur pour arriver à cette compréhension. • Il est facile de faire des tests en présence d’une bonne conception.
  • 43. Ne pas hésiter à utiliser des outils modernes • Legacy != outils désuets • Exemples : – Intégration continue – Dernière version de l’IDE – Dernières versions des librairies et frameworks – Système Legacy dans Docker
  • 44. Ne pas oublier les bases • OOP • Clean Code • Maîtrisez et appliquez les principes SOLID • Boy Scout Rule • Agile Modeling (Scott Ambler)
  • 45. Se prémunir contre le Legacy Code à la base • Les développeurs doivent demander Quoi, Pourquoi et pour Qui avant de trouver le Comment. • Ce n’est pas aux analystes et utilisateurs de leur dire le Comment. • On veut savoir du client/PO qu’est-ce qu’ils veulent, pourquoi ils le veulent et pour qui cela va être utile.
  • 46. Faire la conception en équipe • Les meilleures conceptions sont effectuées en équipe, et non par une seule personne. • La compréhension de l’architecture ainsi que son adoption est répandue dans toute l’équipe. • Pourquoi s’en passer ?
  • 47. Ou du Mob Programming ! • Approche où l’équipe complète (client, analyste et PO aussi) travaille sur la même chose : – Au même endroit – En même temps – Sur le même ordinateur • Un peu similaire au pair programming
  • 48. En résumé, nous avons vu… • C’est quoi du Legacy Code • Comment faire pour le tester • Comment affronter la résistance • Comment s’en prémunir au jour le jour
  • 49. Alors, tester du du Legacy Code, • Met à l’épreuve et renforce nos habilités en: – Programmation Orientée-Objet – Conception & Architecture • Offre un challenge qui peut donc être instructif et amusant ! • Nous rend plus professionnel en bout de ligne.
  • 50. Comment vous en sortez-vous avec le Legacy Code ?
  • 51. Références 1/2 • Podcast Hanselminutes 2016-08-05 « Learning to love Legacy Code with Andrea Goulet from CorgiByte » – http://hanselminutes.com/539/learning-to-love-legacy-code- with-andrea-goulet-from-corgibytes • Patron « Test Specific Subclass » – http://xunitpatterns.com/Test-Specific%20Subclass.html • XKCD Goto – https://xkcd.com/292/
  • 52. Autres références • Lectures suggérées • Beaucoup de connaissances et d’information sur le ‘net
  • 53. Pour nous rejoindre • Karl Métivier – Courriel: kmetivier@facilite.com – LinkedIn: https://www.linkedin.com/in/karlmetivier/fr – Twitter: @karlmet – Blogue: https://excellenceagile.com/ • Yves St-Hilaire – Courriel: yves.sthilaire@gmail.com – LinkedIn: www.linkedin.com/in/yves-st-hilaire – Twitter: @sthiy