Save 37% off PRO during our Black Friday Sale! »

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

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

La vidéo de cette présentation est disponible sur youtube : https://www.youtube.com/watch?v=VKe9EE4MUxk

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.

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

February 08, 2018
Tweet

Transcript

  1. Dette technique : Entropie logicielle & Complexité accidentelle

  2. Dette technique : Entropie logicielle & Complexité accidentelle

  3. 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
  4. « 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
  5. « 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
  6. Votre dette technique est-elle intentionnelle ? La dette involontaire, ça

    n’existe pas !
  7. Dette Technique, Entropie Logicielle & Complexité Accidentelle @lilobase www.arpinum.fr Mon

    twitter
  8. La dette technique c’est quoi finalement ?

  9. 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
  10. 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
  11. 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 difficile Générer de la dette facile à rembourser 
 est très difficile
  12. Mais la dette technique n’est pas une excuse ! Normalization

    of deviance (et vous avez été payés pour l’écrire)
  13. 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 finir à la rue
  14. Mais si ce n’est pas de la dette, qu’est ce

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

    décrépit Il est temps d’utiliser les vrais mots.
  16. 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 »
  17. L’entropie peut être accélérée ou ralentie Entropie Complexité Refactoring accélère

    ralentit
  18. 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
  19. 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
  20. 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 »
  21. 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
  22. 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
  23. La complexité 
 n’est pas linéaire Complexité Taille du système

  24. 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
  25. Et ce n’est pas une architecture microservice, c’est du découplage

    !
  26. Les architectures microservices sont complexes Complexité accidentelle Complexité obligatoire Complexité

    essentielle Le réseau, l’orchestration, le refactoring
  27. Mais alors, la décrépitude de mon code, elle vient d’où

    ?
  28. 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.
  29. 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
  30. De l’agilité managériale On arrive à la fin 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
  31. Avalanche Driven Développement

  32. De l’agilité managériale Et si on faisait des sprints inférieurs

    à une journée ? (continuous delivery)
  33. 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
  34. 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
  35. Pas le temps, on est trop occupés !

  36. Rendez la problématique visible à la direction produit Soyez explicite

    sur les problèmes de Legacy. Arrêtez de faire des promesses intenables
  37. 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
  38. De la glorification 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
  39. Overengineering

  40. 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
  41. 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
  42. Quand on a un marteau, tout ressemble à des clous

    Forte distance entre le métier et son implémentation logicielle Rends difficiles 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
  43. Faire des choses génériques TECHNIQUE MÉTIER GÉNÉRIQUE SPÉCIFIQUE Framework technique

    Framework d’entreprise DDD
  44. Ê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
  45. Overengineering

  46. 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-régression.
  47. 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
  48. 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
  49. Il faut donc éviter de faire « durcir » le

    code « Software is meant to be soft (easy to change) as opposed to hardware »
  50. 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 uns des autres Une des premières causes de dépendance est la dépendance via la base de données
  51. Manque de découplage C1 C2 C3 X X Complexity =

    Si pas de découplage Avec du découplage C1 C2 C3 + + Complexity =
  52. L’architecture hexagonale

  53. 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 complexifiez et couplez deux codes qui n’ont rien à voir
  54. 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 »
  55. Cargo Culting

  56. 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
  57. 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
  58. Le projet de refonte

  59. Le refactoring est un changement de la forme du code

    Refonte vs Refactoring La refonte vise à remplacer un système
  60. 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
  61. « 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
  62. 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. »
  63. 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
  64. Votre refactoring doit être guidé par le métier

  65. Ne partez pas from scratch

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

  67. 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 !
  68. Soyez intransigeant

  69. Pour aller plus loin

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

    nous