Entropie du logiciel : Dette technique & complexité accidentelle — Agile Pays Basque 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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

5. Votre dette technique
   est-elle intentionnelle ?
   

   View Slide

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

   View Slide

7. La dette technique
   c’est quoi finalement ?
   

   View Slide

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
   

   View Slide

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
   

   View Slide

10. Mais votre dette technique
    n’est pas une excuse !
    Normalisation of deviance
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

25. « 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

29. Ê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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. 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)
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

40. Cargo Culting
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

44. Le projet de « refonte »
    • Vos refactoring doivent aussi 

    être guidés par le métier
    • N’oubliez pas l’anti-corruption layer
    • Ne partez pas from scratch
    • Ne faîtes pas de « big bang » refactoring
    

    View Slide

45. Soyez intransigeant
    

    View Slide

46. Pour aller plus loin
    

    View Slide

47. Merci !
    @lilobase www.arpinum.fr
    Si vous voulez 

    travailler avec nous
    

    View Slide