Dette technique et entropie logicielle – Agile Tour Bordeaux 2017

Souvent mal comprise et confondue avec l'érosion du logiciel, la dette technique a mauvaise presse. Elle reste pourtant un processus essentiel (si maitrisé correctement) lors des développements. A contrario, l'entropie logicielle est un phénomène naturel conduisant progressivement le logiciel à perdre en maintenabilité et évolutivité. Nous étudierons les causes d'accélération de cette entropie, mais surtout, comment combattre ce processus qui finit par bloquer l'évolution du logiciel (et au passage sa rentabilité) ? Une conférence ouverte à tous (y compris non développeurs), pour s'intéresser à pourquoi et comment le code source d'un logiciel finit par être immaintenable.

Transcript

1. Dette technique : Entropie logicielle & Complexité accidentelle
2. Crash Report 365 millions de ligne de code 745 applications 160 entreprises 10 secteurs métier 35 % des défauts impactant la sécurité ou la stabilité coût estimé de la dette technique : $3.61 / ligne de code
3. « the ticking time bomb of technical debt is ticking louder and louder, and the clock is counting down faster and faster » Gartner — A ticking bomb
4. « the obligations incurred by a software organization when it chooses an expedient design or construction approach that increases complexity and is more costly in the long term. » Définition de Ward Cunningham
5. Votre dette technique est-elle intentionnelle ?
6. Dette Technique, Entropie Logicielle & Complexité Accidentelle @lilobase www.arpinum.fr Mon twitter
7. La dette technique c’est quoi finalement ?
8. La dette technique est indispensable à un projet Elle permet d’acheter une augmentation rapide de ROI pour le projet Mais avec un taux d’intérêt (élevé) Elle doit donc être générée consciemment, avec parcimonie et avec l’accord du PO
9. La dette technique est indispensable à un projet Les développeurs doivent donc être extrêmement explicites sur la prise de dette Ils ont le dernier mot sur le 
 remboursement de celle-ci La gestion de la dette technique demande une réelle expérience dans le développement
10. Mais la dette technique n’est pas une excuse ! Normalisation of deviance (et vous avez été payés pour l’écrire)
11. Mais si ce n’est pas de la dette, qu’est ce que j’ai ?
12. De la pourriture logicielle Du code toxique Un code source décrépit Il est temps d’utiliser les vrais mots.
13. Lehman’s Laws • "Continuing Change" — a system must be continually adapted or it becomes progressively less satisfactory • "Continuing Growth" — the functional content of a system must be continually increased to maintain user satisfaction over its lifetime • "Increasing Complexity" — as a system evolves, its complexity increases unless work is done to maintain or reduce it • "Declining Quality" — the quality of a system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes
14. Parlons d’entropie Dans la théorie de la communication, nombre qui mesure l'incertitude de la nature d'un message donné à partir de celui qui le précède (L'entropie est nulle lorsqu'il n'existe pas d’incertitude). définition larousse « tendance naturelle d’un système à se désordonner »
15. Et c’est un phénomène naturel La seule façon de ne pas augmenter l’entropie est de ne pas ajouter de ligne de code Ajout de code Augmentation de l’entropie Décrépitude du code source
16. L’entropie peut être accélérée ou ralentie Entropie Complexité accidentelle Refactoring accélère ralentit
17. La complexité accidentelle Complexité accidentelle Complexité obligatoire Complexité essentielle La complexité d’un logiciel dépend de trois facteurs Complexité accidentelle Complexité obligatoire Complexité essentielle Une bonne conception cherche à minimiser la complexité accidentelle
18. Et c’est un processus inexorable Ajout de code Augmentation de l’entropie Pourriture du code source Code legacy
19. Et c’est un processus inexorable Le logiciel n’est plus viable économiquement Certains projets arrivent à ce stade avant même la mise en production Pour les projets critiques cela peut prendre très très longtemps Il coûte plus cher à maintenir qu’il ne rapporte Ajouter une fonctionnalité coûte plus cher que ce qu’elle rapporterait
20. Pour les projets critiques cela peut prendre très très longtemps Et c’est un processus inexorable TMA / souffrance pour les développeurs le code source est complètement pourri et le logiciel cherche à mourir Il continue à rapporter plus d’argent qu’il ne coûte
21. La complexité n’a pas une scalabilité linéaire Complexité Taille du système
22. C’est un processus inexorable, qui ne peut être stoppé Il faut donc limiter la taille d’une code base En maitrisant sa complexité Il faut donc assembler des modules simples et indépendants les uns des autres
23. Et ce n’est pas une architecture micro-service, c’est du découplage !
24. Mais alors, la décrépitude de mon code, elle vient d’où ?
25. Ne pas confondre cause et symptôme Code illisible, bug, etc. sont des symptômes Les causes réelles se trouvent dans les pratiques, la culture de l’équipe Supprimer le « mauvais » code source ne résoudra jamais l’origine du problème de qualité du code
26. Les mêmes causes produisent les mêmes effets « The same cause always produces the same effect, and the same effect never arises but from the same cause. »
27. « les organisations qui définissent des systèmes ... sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation. » La loi de Conway
28. De l’agilité managériale On change en cours de route le fonctionnel du logiciel (on a le droit on fait du scrum) L’équipe n’a pas l’expérience pour construire de façon incrémentale l’architecture Les développeurs accélèrent l’entropie du logiciel accélérant le phénomène de pourrissement
29. Faire des choses génériques TECHNIQUE MÉTIER GÉNÉRIQUE SPÉCIFIQUE Framework technique Framework d’entreprise DDD
30. Être générique « au cas où » « An important result […] is a movement toward simplicity of design. Before I used refactoring, I always looked for flexible solutions. I would wonder how any requirement would change during the life of the system. Because changes were expensive, I would look to build a design that would stand up to the changes I could foresee. The problem with building a flexible solution is that flexible solutions are more complex than simple ones. […] Building flexibility in all these places makes the overall system a lot more complex and expensive to maintain. » - Fowler, Refactoring
31. La première fois n’est jamais terrible Il faut être conscient que l’on ne découvrira pas le domaine métier dès le début Il faut pouvoir facilement refactorer le code existant au fur et à mesure de la découverte du domaine Pour pouvoir refactorer, il est important d’avoir des tests unitaires pour vérifier la non-regression.
32. Il faut donc éviter de faire « durcir » le code Utilisation de seams pour pouvoir étendre facilement le code source : • injection de dépendance • évènements « A good heuristic is that decisions that makes things easier, clearer while keeping options open are the best at reducing development costs. » - mozaicworks
33. Il faut donc éviter de faire « durcir » le code « Software is meant to be soft (easy to change) as opposed to hardware »
34. Dissociation entre le métier et son implémentation Un développeur n’est pas un traducteur
 métier -> technique Son métier est d’implémenter au plus près le métier dans le code source Un expert métier doit pouvoir comprendre ce que fait le code source (DDD)
35. Quand on a un marteau, tout ressemble à des clous Le développeur choisit un outil technique (framework) Il va contraindre son métier à s’adapter à l’outillage technique Il va créer de la distance entre le métier et son implémentation logicielle
36. Quand on a un marteau, tout ressemble à des clous Forte distance entre le métier et son implémentation logicielle Cela va rendre difficile la composition et l’évolution de l’existant pour s’adapter aux changements du métier La technique doit venir en support du métier et s’y adapter et non l’inverse
37. Manque de découplage Afin de pouvoir maintenir la taille du code source sous une taille critique, il faut créer de petits modules Cet avantage est totalement détruit si vous commencez à avoir des modules dépendants les un des autres Une des première cause de dépendance est la dépendance via la base de donnée
38. Manque de découplage C1 C2 C3 X X Complexity = Si pas de découplage Avec du découplage C1 C2 C3 + + Complexity =
39. Tentative de suppression des duplication Il est de bon ton dans notre industrie d’essayer de supprimer les duplications Deux choses sont équivalentes si elles partagent la même intention dans le même contexte En essayant de rassembler ces deux intentions, vous complexifiez et couplez deux codes qui n’ont rien à voir
40. Essayer d’optimiser prématurément L’optimisation est un problème complexe qui ajoute souvent de la complexité Optimiser avant même d’avoir identifié les causes des problèmes de performance est donc contre indiqué L’optimisation peut aussi être une notion de « cleverness »
41. Cargo Culting
42. Travailler sur un code source existant sans accélérer l’entropie
43. La règle des boy-scouts « Always leave the campground cleaner than you found it. » - Robert C. Martin
44. Le syndrome du second système « This second is the most dangerous system a man ever designs. […] The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. » - Fred Brooks
45. Le projet de « refonte » • Vos refactoring doivent aussi 
 être guidés par le métier • Redécouvrer vos Bounded Contexts • N’oubliez pas l’anti-corruption layer • Ne partez pas from scratch • Ne faîtes pas de « big bang » refactoring
46. Soyez intransigeant
47. Pour aller plus loin
48. Merci ! @lilobase www.arpinum.fr Si vous voulez 
 travailler avec nous Le 7 décembre : bordeaux.ncrafts.io