Sur certains projets, on peut se demander s'il y a encore vraiment un pilote pour sauver l'application. Peut-être est-ce lié au vieillissement de nos applications de gestion désormais considérées comme "Legacy" ? Nous vous présenterons les recettes que nous avons pu mettre en oeuvre de manière pragmatique pour améliorer progressivement la qualité des applications tout en ajoutant des fonctionnalités. Il n'y aura pas de "Bullshit", pas de "FOA" (Fashion Oriented Architecture) : seulement des exemples de bon sens éprouvés sur de nombreux projets.

1. Pimp my Legacy
par François Ostyn
@ostynf / @soatexpert
http://blog.soat.fr
1

2. Disclaimer
2

3. Résumé
• Pourquoi parler de legacy ?
• Qui n’a jamais dû reprendre une application développée avec de mauvaises
pratiques ?
• Comment améliorer les choses ?
3

4. Speaker
• Depuis plus d’une dizaine d’année dans l’informatique
• Actuellement responsable du pôle Expert Java chez So@t
• Architecte applicatif Java
• Une devise que j’apprécie :
«La simplicité est la sophistication ultime» (Léonard De Vinci : 1452-1519)
4

5. Mais pourquoi vous parler de
« Pimp My Legacy ?»
5

6. Un nouveau film ?
Pimp My Legacy
6

7. Un nouvelle émission ?
Pimp
My
Legacy
7

8. Un peu d’Histoire de l’Informatique
8

9. Les premiers ordinateurs datent des années 1940...
9

10. ...et les langages de programmations sont arrivés.
10

11. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
16 ans
11

12. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
JDK 1.0
16 ans
11

13. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
JDK 1.0
JDK 1.1
16 ans
11

14. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
JDK 1.0 J2SE1.2
JDK 1.1
16 ans
11

15. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
JDK 1.0 J2SE1.2 J2SE1.3
JDK 1.1
16 ans
11

16. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
JDK 1.0 J2SE1.2 J2SE1.3 J2SE1.4
JDK 1.1
16 ans
11

17. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
JDK 1.0 J2SE1.2 J2SE1.3 J2SE1.4 J2SE1.5
JDK 1.1
16 ans
11

18. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
JDK 1.0 J2SE1.2 J2SE1.3 J2SE1.4 J2SE1.5 Java SE1.6
JDK 1.1
16 ans
11

19. Le langage Java
2000 2005 2010
96 97 98 99 01 02 03 04 06 07 08 09 11 12 13
JDK 1.0 J2SE1.2 J2SE1.3 J2SE1.4 J2SE1.5 Java SE1.6 Java SE1.7
JDK 1.1
16 ans
11

20. Que veut le client ?
• Que son application ne coûte pas cher
• Ajouter beaucoup de fonctionnalités
• Pour hier
• Ne pas perturber les utilisateurs
12

21. Solutions
• Modifier l’espace-temps
• Travailler 24h/24
• Négocier
13

22. Conclusion
Ne faisons rien, ça fonctionne déjà...
Avant Après
14

23. Questions ?
15

24. Ne faisons rien ?
NON
16

25. Ne faisons rien ?
NON
On peut toujours améliorer les
choses
16

26. Mais que pouvons-nous améliorer ?
17

27. La stabilité
18

28. La stabilité
Les performances
19

29. La stabilité
Les performances
L’exploitation
20

30. La stabilité
Les performances
L’exploitation
Le confort de l’utilisateur
21

31. Existe-t-il une recette magique ?
22

32. Existe-t-il une recette magique ?
NON 23

33. Juste des bonnes pratiques basées
sur l’expérience.
24

34. Règle
Être humble et ne pas dénigrer ce
qui a été fait.
25

35. Règle
Être capable de retrouver les
sources et documentations.
26

36. Règle
Quand on ne sait pas où l’on va, il faut une
carte pour se guider.
27

37. Règle
Ne pas mélanger le code «métier» et le
code «technique».
28

38. Règle
Avant de réinventer un framework, regarder
s’il n’en existe pas un.
29

39. Règle
Quand une modification est effectuée, il
faut être capable de revenir en arrière.
30

40. Règle
Les frameworks ont été créés pour
simplifier les applications et non pas
pour les complexifier.
31

41. Règle
Maîtriser le build.
32

42. Règle
Ne pas être tenté par le FOA
(Fashion Oriented Architecture).
33

43. Règle
Ne pas penser au performances
en premier lieu.
Donald Knuth : «premature optimization is the root of all evil»
34

44. Règle
Ce qui fait la valeur d’une société,
ce sont ses données et son savoir
faire.
35

45. Conclusion
36

46. Il existe aussi CQRS
Séparation architecturale entre les commandes et les
requêtes. (voir conférence à laquelle vous n’avez pas
assisté... ;-) ).
37

47. Rendez-vous l’année prochaine à
Devoxx France !
38

48. Merci à tous
39

49. Questions ?
40