Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Entropie du logiciel : dette technique & complexité accidentelle — Agile France 2017

Entropie du logiciel : dette technique & complexité accidentelle — Agile France 2017

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.

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

June 15, 2017
Tweet

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 si ce n’est pas de la dette, qu’est ce

    que j’ai ?
  11. De la pourriture logicielle Du code toxique Un code source

    décrépit Il est temps d’utiliser les vrais mots.
  12. 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 »
  13. 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
  14. Qui peut être accéléré ou ralenti Entropie Complexité accidentelle Refactoring

    accélère ralentie
  15. 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
  16. Et c’est un processus inexorable Ajout de code Augmentation de

    l’entropie Pourriture du code source Code legacy
  17. 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
  18. 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
  19. 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
  20. Mais alors, la décrépitude de mon code, elle vient d’où

    ?
  21. 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
  22. 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)
  23. « 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
  24. 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érifier la non-regression.
  25. 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
  26. 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
  27. 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 complexifiez et couplez deux codes qui n’ont rien à voir
  28. 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é Encore pire si le développeur tente d’implémenter une solution « intelligente » mais illisible
  29. 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)
  30. Cargo Culting

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

  32. 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 fires inside. » - James Q. Wilson and George L. Kelling
  33. La règle des boy-scouts « Always leave the campground cleaner

    than you found it. » - Robert C. Martin
  34. 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
  35. 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. »
  36. 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. »
  37. Pour aller plus loin

  38. Merci ! @lilobase www.arpinum.fr Si vous voulez 
 travailler avec

    nous