Réfacto ou réécriture ?

On entend souvent le mot "refacto" dans le quotidien de développement produit. Parfois, on se demande si les gens comprennent ce qu'ils disent...
Un regard sur le pratique de refactoring, des malentendus communs et des idées d'amélioration.

Transcript

1. Réfacto ou réécriture ? Soyons clair dans nos discours…
2. Merci à tous nos sponsors !
3. Qui suis-je ? • Vieux agiliste • eXtreme programmeur • Formateur agile et technique A noter: présentation en fr_US @nostradamnit@mamot.fr /in/samcranford/
4. ATTN : version 0.2 Cette présentation est un cours de réalisation Cette session sera participative et interactive
5. Pourquoi ? Abuse de langage Manque de clarté dans nos communications Manque de compréhension entre techos et mgmt Huh ?
7. Retour à la base Les conférences, ça fait une vingtaine d’années qu’on en fait Pour certaines personnes, ça ne fait pas si longtemps Ce sera bien de revoir les bases Les choses simples ont tendance à perdre leur simplicité avec le temps legoideas.si/simple-duplo-animals/lego-duplo-rooster/
8. Refactoring Un des mots le plus mal compris de l’informatique Ça veut dire quoi exactement ? En français ?! Refactorisations ?! Remaniement ?! Réusinage ?!? https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/
9. La définition Changer la structure interne d’un logiciel sans changer son comportement externe Peut être un nom et un verbe nom: petite modification interne d’un logiciel pour l’améliorer sa compréhension et rendre plus facile à modifier verbe: appliquer une série de petites modifications à un logiciel sans changer son comportement externe
10. Comment ça ? Au plus simple, ça peut être de changement de nom de variables, nom de fonction. Le but est de rendre le code plus lisible, plus facilement modifiable https://tammeleht.wordpress.com/2015/12/28/refactoring /
11. D’où vient cette idée étrange ? Il était formalisé par Martin Fowler dans les années 90 C’est un concept qui est intégral dans l’eXtreme Programming (XP) Depuis il est abusé et mal compris dans le monde entier https://www.thoughtworks.com/profiles/leaders/martin-fowler
12. Refactoring, le livre Martin a écrit, en 1999, le livre éponyme sur le sujet. Il y décrit le processus, les motivations, et surtout, comment faire. Un majeur partie du livre constitue un catalogue de refactorings spécifique. En 2018, il écrit une seconde édition du livre, avec notamment des exemples en Javascript au lieu de Java.
13. C’est quoi, exactement ? Ça fait partie du processus d’ecriture d’un logiciel de façon itérative. On reconnait que le code produit est imparfait ; qu’il vaut mieux le revoir et réviser. L’imperfection peut être dans la structure, et non le résultat. https://medium.com/geekculture/functional-test-refactoring-extract-function-5572554c0677
14. eXtreme Programming L’extreme programming (ou XP), en français « la programmation extrême », est une méthode agile de génie logiciel privilégiant l'aspect réalisation d'une application, sans pour autant négliger l'aspect gestion de projet. Elle pousse à l'extrême des principes simples, d'où son nom. La programmation poussée à l'extrême est adaptée aux équipes réduites ayant des besoins changeants. [https://fr.wikipedia.org/wiki/Extreme_programming]
15. eXtreme Programming (bis repetita) Dans le livre Extreme Programming Explained, la méthode est définie comme • une tentative de réconcilier l'humain avec la productivité, • un mécanisme pour faciliter le changement social, • une voie d'amélioration, • un style de développement, • une discipline de développement d'applications informatiques. Son but principal est de réduire les coûts du changement. https://fr.wikipedia.org/wiki/Extreme_programming
16. eXtreme Programming (bis repetita) Les principes de cette méthode existent depuis longtemps. L'originalité de la méthode est de les pousser à l'extrême : • la revue de code sera faite en permanence (par un binôme) ; • les tests seront faits systématiquement avant chaque mise en œuvre ; • le code sera retravaillé tout au long du projet (refactoring ou remaniement du code) ; • la solution la plus simple sera toujours celle qui sera retenue ; • des métaphores seront définies et évolueront en concomitance ; • les modifications seront faites plusieurs fois par jour ; • des cycles de développement très rapides faciliteront l'adaptation au changement. https://fr.wikipedia.org/wiki/Extreme_programming
17. Développement Piloté par les Tests Le processus préconisé par TDD comporte cinq étapes : 1. écrire un seul test qui décrit une partie du problème à résoudre ; 2. vérifier que le test échoue, autrement dit qu'il est valide, c'est- à-dire que le code se rapportant à ce test n'existe pas ; 3. écrire juste assez de code pour que le test réussisse ; 4. vérifier que le test passe, ainsi que les autres tests existants ; 5. remanier le code, c'est-à-dire l'améliorer sans en altérer le comportement, qu'il s'agisse du code de production ou du code de test. https://fr.wikipedia.org/wiki/Extreme_programming https://www.hiberus.com/crecemos-contigo/todo-lo-que-necesitas-saber-de-tdd-en-3-minutos/
18. Pourquoi refactor-er ? Une raison souvent avancée pour faire du refacto est de rendre le code propre. Clean code gnagnagna… Selon Robert Martin, le but principal sera économique. Le but est de rendre le code plus facilement modifiable, afin de pouvoir y ajouter de nouvelles fonctionnalités pour le mieux vendre
19. Un avenir meilleur Du logiciel bien réfactorisé est plus facile à comprendre. Tu te remercieras quand tu y reviendras dans 6 mois, ou 6 jours… L’entreprise te remerciera lorsqu’ils arrivent toujours à y ajouter de fonctionnalité, et donc de la valeur. Cha-ching ! http://www.economist.com/node/21548491
20. Code smells C’est une métaphore pour du code qui pue, qui te brule les yeux. Il y a gavé de formes différentes : - la classe ou méthode trop longue - la jalouse de fonctionnalité - l’intimité inappropriée - l’obsession primitive - la duplication - … https://refactoring.guru/refactoring/smells https://imgs.xkcd.com/comics/code_quality.png
21. Refactoring to … Du coup, une fois la mauvaise odeur identifiée, comment faire ? Il existe tout un catalogue de réfactos possible. Les Internets en regorgent ! Mais surtout, le livre éponyme en est un catalogue à lui-même. Et il en existe gavé d’autres aussi !
22. Refactoring to Patterns Patterns ou Patrons de conception Les patrons de conception (design patterns) sont des solutions classiques à des problèmes récurrents de la conception de logiciels. Chaque patron est une sorte de plan ou de schéma que vous pouvez personnaliser afin de résoudre un problème récurrent dans votre code. https://refactoring.guru/fr/design-patterns
23. Refactoring to Domain-Driven Design Le thème commun de DDD est les Patrons de conception • Aggregates • Entities • Repositories • Factories https://www.jimmybogard.com/domain-driven-refactoring-intro/ Au fil des années, la seule technique vraiment efficace que j'ai trouvée pour créer du code hautement cohérent et maintenable est le refactoring. Mais il semble que ce soit un art perdu : très peu de développeurs que je rencontre ou d'équipes avec lesquelles je travaille considèrent le refactoring comme une compétence essentielle et requise. - Jimmy Bogard
24. Prérequis Un prérequis essentiel pour pouvoir faire du réfacto est d’avoir un moyen de vérifier le non-changement du comportement. C’est-à-dire, des tests. Malheureusement, il y a énormément du code de production sans tests, même pas manuel. Portant, il y a énormément de méthodes pour vérifier le bon fonctionnement de logiciel
25. Code legacy Il est difficile de parler de réfactoring sans que le mot Legacy Code arrive. Quésaco ? Il y a encore gavé de définitions… - du code existant - du code existant écrit par quelqu’un qui n’est plus là - surtout, du code existant, en production, qui gagne de l’argent - et surtout, surtout, du code existant qu’on veut/doit changer
26. Refactoring Malapropism Dès 2004, Martin Fowler a déjà détecté des abuses de langage. Il écrit un article de blog sur le sujet, précisant certains détails. - Refactoring ne prend pas des jours - Le logiciel n’est pas en dysfonction pendant ces jours - On refactor de logiciel spécifiquement - Refactoring est une technique très spécifique, qui modifie un logiciel avec un comportement bien défini https://martinfowler.com/bliki/RefactoringMalapropism.html
27. Réécriture Souvent, lorsqu'une entreprise est confrontée des problèmes de legacy code, à un moment donnée, quelqu’un va dire. « Il faut tout jeter et recommencer » Et là commence, the Big Rewrite.
28. The Big Rewrite La grande réécriture est souvent une décision venant d’en haut. Il suit généralement une série de déceptions vécues par la direction, qui veut des évolutions plus fluides du logiciel, normalement pour répondre aux demandes des utilisateurs. Fréquemment le raisonnement est que ce sera plus rapide de refaire à neuf, au lieu de continuer d’essayer de modifier l’existant. Malheureusement, ce raisonnement s’avere faux, d’experience.
29. Les écueils de la Grande Réécriture De vouloir tout refaire à neuf ne vient pas sans risques. Parmi eux : - Ça prendra (beaucoup) plus de temps que prévu - Refaire les mêmes fonctionnalités ne satisfera pas les clients - L’equipe devra continuer de maintenir l’existant - Les détails de fonctionnalité ne sont pas évidents à extraire/definir - L’equipe s’epuissera, et la direction aussi - Sous pression, la qualité démunirait - Les clients seront très lents à migrer - A la fin, il y aura deux systèmes à maintenir
30. Fin de l’histoire De mon expérience personnelle, et de l’expérience collective, la Grande Réécriture finit mal. Le client n’est rarement satisfait La direction n’est rarement satisfaite Les équipes sont épuisées et dégoûtées d’avoir produit un logiciel de qualité moyen au mieux…
31. Réstructuration Il existe un juste milieu entre réécriture et refactoration classique. Dans son excellent livre, Working Effectively with Legacy Code, Michael C. Feathers présente plusieurs façons pour restructurer un logiciel afin de pouvoir faire du refacto correcte, avec le soutien des tests.
32. References Kent Beck et Ron Jeffries ont aussi écrit plusieurs livres très intéressant, dans lesquels on parle de refactoring. C’est normal, tous les deux sont de co-createurs d’eXtreme Programming, et donc Refactoring est de second nature.
33. Merci ! Merci aux organisateurs et bénévoles qui font en sort que cet événement ait lieu. Merci d’etre venu m’ecouter
34. Legalese (lēˌgə-lēzˈ, -lēsˈ) Cette présentation est sous les licences • Beerware • WTFPL All images used without explicit permission, but with attribution