Le document aborde les défis du développement sur du code legacy, souvent mal écrit et sans tests, tout en soulignant son importance et la nécessité de le modifier. Il propose des stratégies pour refactorer de manière sécurisée, comme l'écriture de tests et la modification progressive du code. Enfin, il évoque des concepts comme la propriété collective du code et des pratiques de rétroaction comme les revues de code.

1. Développer efficacement avec du
code legacy
Mathieu Gandin
@octomga

2. La plupart du temps on se
retrouve à développer sur
une application dont le code
est relativement propre …
© OCTO 2012 2

3. … mais en vrai on se
retrouve souvent à
développer sur du code
Legacy…
© OCTO 2012 3

4. Du code que tu n’as pas écrit
Du code sans test
Du vieux code
N’importe quel langage existant
Du code qui n’est plus supporté
Du code avec des vieilles techno
Du code de la version précédente
© OCTO 2012 4

5. Tu peux fuir le code legacy …
© OCTO 2012 5

6. Tu peux maudire le code
© OCTO 2012
legacy … 6

7. … Mais en ce moment, beaucoup
(beaucoup) de code legacy est en
cours d’écriture …
© OCTO 2012 7

8. … Et c’est important car
Du code legacy doit encore être étendu
Du code legacy doit être corrigé
Du code legacy doit changer
technologiquement
8

9. © OCTO 2012
TDD 9

10. « Pour refactorer j’ai besoin
d’avoir des tests
pour mettre des tests en
place, j’ai besoin
de refactorer … »
© OCTO 2012 10

11. Live Coding 11

12. Identifier les éléments que l’on
souhaite changer
Trouver un point d’entrée
Ecrire un test
Casser les dépendances
Modifier le code
© OCTO 2012 12

13. Sprout class & Sprout
Method
© OCTO 2012 13

14. Pourquoi être si prudent ?
Avec une certaine masse de code il est facile
de faire des erreurs sans s’en rendre compte
Préserver les comportements
© OCTO 2012 14

15. Singleton (variable globale)
Instanciation interne (hardcodé
(ça casse les tests …))
Code procédural (c’est long (très)
à tester)
15

16. Collective Ownership 16

17. © OCTO 2012 Boy Scout Rule 17

18. © OCTO 2012
Retrospective 18

19. © OCTO 2012
Code Review 19

20. Coding Dojo 20

21. « Organizations which design
systems are constrained to produce
designs which are copies of the
communication structures of these
organizations »
© OCTO 2012 21

22. Questions ?
22