Entropie du logiciel : dette technique & complexité accidentelle

Slide 1

Slide 1 text

Dette technique : Entropie logicielle & Complexité accidentelle

Slide 2

Slide 2 text

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

Slide 3

Slide 3 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 4

Slide 4 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 5

Slide 5 text

Votre dette technique est-elle intentionnelle ?

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

La dette technique c’est quoi ﬁnalement ?

Slide 8

Slide 8 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 9

Slide 9 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 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 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 13

Slide 13 text

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

Slide 14

Slide 14 text

Qui peut être accéléré ou ralenti Entropie Complexité accidentelle Refactoring accélère ralentie

Slide 15

Slide 15 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 16

Slide 16 text

Et c’est un processus inexorable Ajout de code Augmentation de l’entropie Pourriture du code source Code legacy

Slide 17

Slide 17 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 18

Slide 18 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 19

Slide 19 text

Qui ne peut pas être stoppé Il faut donc limiter la taille d’une code base C’est pourquoi l’on assemble des modules logiciels indépendants et de petites tailles Ce qui est la base d’une bonne conception logicielle

Slide 20

Slide 20 text

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

Slide 21

Slide 21 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 22

Slide 22 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 bon code source doit être compréhensible par un expert métier (principe du DDD)

Slide 23

Slide 23 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 24

Slide 24 text

La première fois n’est jamais terrible Il faut être conscient que l’on ne découvrira pas le domaine technique 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-regression.

Slide 25

Slide 25 text

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

Slide 26

Slide 26 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 un des autres Une des première cause de dépendance est la dépendance via la base de donnée

Slide 27

Slide 27 text

Tentative de suppression des duplication Il est de bon ton dans notre industrie d’essayer de supprimer les duplications Deux éléments de même nom peuvent représenter des intentions différentes dans des contextes différents En essayant de rassembler ces deux intentions, vous complexiﬁez et couplez deux codes qui n’ont rien à voir

Slide 28

Slide 28 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é Encore pire si le développeur tente d’implémenter une solution « intelligente » mais illisible

Slide 29

Slide 29 text

Etre générique à priori En essayant de construire des solutions génériques Vous imaginez des cas d’usages qui n’existent pas, et qui vont souvent se révéler faux Une variante encore pire est de faire des développements « au cas où » (et ça peut venir du PO)

Slide 30

Slide 30 text

Cargo Culting

Slide 31

Slide 31 text

Travailler sur un code source existant sans accélérer l’entropie

Slide 32

Slide 32 text

La loi de la fenêtre brisée « Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light ﬁres inside. » - James Q. Wilson and George L. Kelling

Slide 33

Slide 33 text

La règle des boy-scouts « Always leave the campground cleaner than you found it. » - Robert C. Martin

Slide 34

Slide 34 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 35

Slide 35 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 thesame cause. »

Slide 36

Slide 36 text

Big bang refactoring « Never attempt "Big Bang". It almost always blows in your face, since it's a high-risk, desperate measure when everything else has failed. »