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.

Arnaud LEMAIRE

June 15, 2017
Tweet

More Decks by Arnaud LEMAIRE

Other Decks in Programming

Transcript

  1. Dette technique : Entropie logicielle &
    Complexité accidentelle

    View full-size 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 full-size 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 full-size 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 full-size slide

  5. Votre dette technique
    est-elle intentionnelle ?

    View full-size slide

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

    View full-size slide

  7. La dette technique
    c’est quoi finalement ?

    View full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  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 »

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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)

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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)

    View full-size slide

  30. Cargo Culting

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. Pour aller plus
    loin

    View full-size slide

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

    travailler avec nous

    View full-size slide