Dette technique et entropie du logiciel — Swcrafters Rennes & Nantes, JUG Tours

Slide 1

Slide 1 text

Dette technique : Entropie logicielle & Complexité accidentelle

Slide 2

Slide 2 text

Dette technique : Entropie logicielle & Complexité accidentelle

Slide 3

Slide 3 text

Crash Report 365 millions de lignes 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

Slide 4

Slide 4 text

« 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

Slide 5

Slide 5 text

« 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éﬁnition de Ward Cunningham

Slide 6

Slide 6 text

Votre dette technique est-elle intentionnelle ? La dette involontaire, ça n’existe pas !

Slide 7

Slide 7 text

Dette Technique, Entropie Logicielle & Complexité Accidentelle @lilobase www.arpinum.fr Mon twitter

Slide 8

Slide 8 text

La dette technique c’est quoi ﬁnalement ?

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

La dette technique est indispensable à un projet La gestion de la dette technique demande une réelle expérience dans le développement Générer de la dette c’est très facile Générer de la dette avec un faible taux d’intérêt c’est déjà plus difﬁcile Générer de la dette facile à rembourser   est très difﬁcile

Slide 12

Slide 12 text

Mais la dette technique n’est pas une excuse ! Normalization of deviance (et vous avez été payés pour l’écrire)

Slide 13

Slide 13 text

Mais la dette technique n’est pas une excuse ! Prendre de la dette sur un système qui est déjà endetté, c’est l’équivalent d’un crédit subprime Vous avez de bonnes chances de ﬁnir à la rue

Slide 14

Slide 14 text

Mais si ce n’est pas de la dette, qu’est ce que j’ai ?

Slide 15

Slide 15 text

De la pourriture logicielle Du code toxique Un code source décrépit Il est temps d’utiliser les vrais mots.

Slide 16

Slide 16 text

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 »

Slide 17

Slide 17 text

L’entropie peut être accélérée ou ralentie Entropie Complexité Refactoring accélère ralentit

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Et c’est un processus inexorable Ajout de code La complexité augmente Hausse de l’entropie du système Décrépitude du code source La seule façon de ne pas augmenter l’entropie est de ne pas ajouter de lignes de code

Slide 20

Slide 20 text

Et c’est un processus inexorable Code source pourri Le logiciel n’est plus viable économiquement Et l’on arrive au célèbre : « Code Legacy »

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

La complexité   n’est pas linéaire Complexité Taille du système

Slide 24

Slide 24 text

La complexité   n’est pas linéaire Pour maitriser la complexité d’une code base Il faut limiter sa taille En assemblant des modules simples et indépendants les uns des autres

Slide 25

Slide 25 text

Et ce n’est pas une architecture microservice, c’est du découplage !

Slide 26

Slide 26 text

Les architectures microservices sont complexes Complexité accidentelle Complexité obligatoire Complexité essentielle Le réseau, l’orchestration, le refactoring

Slide 27

Slide 27 text

Mais alors, la décrépitude de mon code, elle vient d’où ?

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

De l’agilité managériale On arrive à la ﬁn du sprint La vélocité n’est pas bonne, il reste beaucoup de user story L’équipe génère de la « dette technique » pour accélérer Il faut résorber la dette au début du sprint suivant

Slide 31

Slide 31 text

Avalanche Driven Développement

Slide 32

Slide 32 text

De l’agilité managériale Et si on faisait des sprints inférieurs à une journée ? (continuous delivery)

Slide 33

Slide 33 text

Et on peut généraliser Les temps de développement sont trop longs L’équipe n’arrive pas à fournir à temps les fonctionnalités L’équipe génère de la « dette technique » pour accélérer Il faut prendre le temps de résorber la dette

Slide 34

Slide 34 text

Jusqu’à la sortie de route Mais on n’a pas le temps La complexité du système le rend ingérable Panique / Code legacy Il faut prendre le temps de résorber la dette

Slide 35

Slide 35 text

Pas le temps, on est trop occupés !

Slide 36

Slide 36 text

Rendez la problématique visible à la direction produit Soyez explicite sur les problèmes de Legacy. Arrêtez de faire des promesses intenables

Slide 37

Slide 37 text

De la glorification de la complexité Il y a une forme de glorification d’une solution particulièrement complexe Encore plus perverse, cette glorification se fait souvent au niveau des outils (kafka, spark, …) Vérifiez systématiquement si la complexité de la solution est bien fonction de la complexité du problème

Slide 38

Slide 38 text

De la gloriﬁcation de la complexité Faire simple n’est pas facile Ne pas confondre simplicité et facilité, complexité et compliqué La facilité est subjective quand la simplicité est objective

Slide 39

Slide 39 text

Overengineering

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Quand on a un marteau, tout ressemble à des clous Forte distance entre le métier et son implémentation logicielle Rends difﬁciles 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

Slide 43

Slide 43 text

Faire des choses génériques TECHNIQUE MÉTIER GÉNÉRIQUE SPÉCIFIQUE Framework technique Framework d’entreprise DDD

Slide 44

Slide 44 text

Ê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

Slide 45

Slide 45 text

Overengineering

Slide 46

Slide 46 text

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ériﬁer la non-régression.

Slide 47

Slide 47 text

Il faut donc éviter de faire « durcir » le code « A good heuristic is that decisions that makes things easier, clearer while keeping options open are the best at reducing development costs. » - mozaicworks

Slide 48

Slide 48 text

Garder les options ouvertes Utilisation de seams pour pouvoir étendre facilement le code source : • Injection de dépendance • Évènements pour gérer les « effets de bord » métier

Slide 49

Slide 49 text

Il faut donc éviter de faire « durcir » le code « Software is meant to be soft (easy to change) as opposed to hardware »

Slide 50

Slide 50 text

Manque de découplage Aﬁn 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 uns des autres Une des premières causes de dépendance est la dépendance via la base de données

Slide 51

Slide 51 text

Manque de découplage C1 C2 C3 X X Complexity = Si pas de découplage Avec du découplage C1 C2 C3 + + Complexity =

Slide 52

Slide 52 text

L’architecture hexagonale

Slide 53

Slide 53 text

Tentative de suppression des duplications 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 complexiﬁez et couplez deux codes qui n’ont rien à voir

Slide 54

Slide 54 text

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 identiﬁé les causes des problèmes de performance est donc contre indiqué L’optimisation peut aussi être une notion de « cleverness »

Slide 55

Slide 55 text

Cargo Culting

Slide 56

Slide 56 text

There is no silver bullet. « We hear desperate cries for a silver bullet – something to make software costs drop as rapidly as computer hardware costs do…. Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any. » - Fred Brooks

Slide 57

Slide 57 text

L’aliénation technique « La plus forte cause d'aliénation dans le monde contemporain réside dans cette méconnaissance de la machine, qui n'est pas une aliénation causée par la machine, mais par la non-connaissance de sa nature et de son essence » - Simondon

Slide 58

Slide 58 text

Le projet de refonte

Slide 59

Slide 59 text

Le refactoring est un changement de la forme du code Refonte vs Refactoring La refonte vise à remplacer un système

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

« Les organisations qui déﬁnissent 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

Slide 62

Slide 62 text

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. »

Slide 63

Slide 63 text

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 ﬁrst one. » - Fred Brooks

Slide 64

Slide 64 text

Votre refactoring doit être guidé par le métier

Slide 65

Slide 65 text

Ne partez pas from scratch

Slide 66

Slide 66 text

Ne laissez pas l’ancien système corrompre le nouveau

Slide 67

Slide 67 text

La prochaine fois qu’une partie du SI cherche à mourir, faites qu’elle n’entraine pas tout le système avec elle. Découplez, sans faire de microservices !