2017-06-15
Mes notes sur la session de @Lilobase à @AgileFrance 2017.
Voir aussi : les slides de la session.
Qu'est-ce qui fait qu'un système logiciel est pourri ? Note : au niveau système, pas au niveau ligne de code.
Constatation dans des études :
- Crash Report (voir slides)
- les défauts coûtent cher
- Gartner
- défauts de plus en plus fréquents
- de plus en plus de bases de codes vieillissante
Au sens de Ward Cunningham : http://wiki.c2.com/?WardExplainsDebtMetaphor
Quelques caractéristiques de la dette Technique :
- Choisi à un instant t pour aller plus vite
- ≠ de subi
- Question à vous poser : votre dette technique est-elle intentionnelle ?
Chez nous (Arpinum) : on utilise la dette technique choisie tout les jours.
On achète une dette avec un taux d'intérêt (car le cout augmente tout seul avec le temps)
PO : il est au courant, on lui demande si ça vaut le coup
En tant que dev, il faut aller en parler au fonctionnel. C'est le business qui achète la dette.
Autre condition : c'est les devs qui ont le dernier mot sur le remboursement de celle-ci ← le PO le sait au moment où il l'achète. Tant pis si l'objectif de sprint n'est pas atteint.
- Sans ça, la code base est foutue
- Nécessite d'avoir une base de code facile à changer, facile à refactorer
Ne pas utiliser "Dette Technique" pour parler de "Pourriture logicielle" ("Software rot").
Plus sympa comme mot : "du code source décrépit".
Il est important quand on discute avec les fonctionnels de faire la distinction.
Tendance naturelle d'un système à évoluer vers "plus de désordre"
Def. d'entropie dans la théorie de la communication (augmentation de l'incertitude dans la chaîne de communication)
Seule façon de ne pas ajouter d'entropie = ne pas ajouter de code :)
On ne peut pas arrêter l'entropie.
- La complexité accidentelle accélère l'augmentation de l'entropie
Si on ne peut pas arrêter l'entropie, comment la ralentir ?
- Le refactoring ralentit l'augmentation de l'entropie
- Limiter la code base, faire 5 projets à 1M plutôt qu'un projet à 5M.
On ne peut pas réduire la complexité essentielle d'un système (implémenter une division est plus complexe qu'implémenter une addition), donc chercher à réduire la complexité accidentelle (cf. slides).
Comment augmenter la complexité accidentelle ? Il suffit de choisir de prendre un framework entreprise pour faire une petite application.
Un bon développeur est celui qui réussi à réduire la complexité accidentelle au minimum.
Dans le secteur banque et assurance, des logiciels immondes qui tiennent depuis des 10aines d'années, mais comme il y a beaucoup d'argent le logiciel reste viable économiquement.
Exemple de TMA : le code source est pourri et cherche à mourir mais on injecte 10M par an dans un logiciel qui gère 200M par an.
Si nos devs veulent devenir chef de projet = signe qu'on fait bosser les devs sur du code pourri (ils préfèrent faire de l'excel que coder, WTF!?)
L'agilité managériale (sans le savoir faire technique) :
- Équipes techniques qui n'ont pas l'expérience pour construire une architecture de façon incrémental (ce qui est très difficile par ailleurs)
- Si on ne sait pas faire ça techniquement, ce n'est pas la peine de dire "on fait de l'agile donc peut changer en cours de route."
Écart entre métier et code :
- Le développeur n'est pas un traducteur du métier. Il implémente au plus près du métier, en utilisant le même language. (Cf. DDD)
Loi de Conway : cf PeopleWare (De Marco).
Pas possible de trouver la bonne solution du premier coup ⇒ il faut pouvoir facilement refactorer le code existant. C'est dangereux si on n'a pas de tests unitaires :)
- Si vous ne faites pas de tests unitaires, n'essayez pas de faire de l'agile.
Durcissement du code :
- Eviter le durcissement du code source, cf techniques de seams (coutures) comme injection de dépendence et événements.
- La BDD est un des pires trucs qui durcit le code ! Faire du MDA (Model Driven Architecture) = code très durcit. Ne pas faire d'agile dans ce cas.
Les règles métier ne sont pas dans la BDD, une BDD n'est pas du métier, c'est un outil pour faire des snapshots.
Manque de découplage.
Attention, ne pas supprimer systématiquement les duplications car en fonction du contexte et de l'intention deux mêmes mots ont un sens différent
- Facture pour shipping (poids, taille, adresse) != facture financière (pour prendre des décisions de budget)
- Si contexte différent ou intention différente, ce n'est pas de la duplication.
Pas d'optimsation prématuré. Un bon développeur est un dev qui écrit du code simple, ce qui est super compliqué à faire. Attention aux devs décrits comme des "génis" et "super héros".
Le "framework générique technique à priori" = pourri :
- Comment faire rentrer les cas d'usages métier dans les cas d'usages qu'on a imaginés au début en concevant le framework ?
Cargo Cult : essayer de répliquer quelque-chose sans le comprendre
- Richard Feynmann (Cargo Cult Science)
- "Je vais essayer d'utiliser les mêmes libs que Netflix alors que je n'ai pas les mêmes besoin ni les mêmes problèmes." Alors on se retrouve avec les mêmes pbs qu'eux alors qu'on ne les avait pas au départ.
Fenêtre brisée
- Si les devs arrivent sur un code source au cordeau, ils vont faire plus gaffe.
- Ne pas laisser les petites merdes trainer
- Pas de fonction de plus de 10 lignes de code, et pas plus de 3 paramètres
Boy scout rule
Le syndrome du 2ème système (Fred Brooks) : c'est le plus dangereux car on a la confiance, on fait moins attention alors qu'on n'a pas encore réellement l'expérience. Tendance à mettre dans le 2e tout ce qu'on n'avait pas pu mettre dans le premier.
- Alors, en être conscient (sur les refontes par exemples) et bien prévenir : attention, c'est dangereux, faire gaffe.
Si une équipe a déjà produit du code de mauvaise qualité, elle va continuer à le faire
- faire venir des gens meilleurs, ou faire que l'équipe devienne meilleure
Agilité : attention, les mêmes effets ne viennent pas forcément des mêmes causes
Ne jamais faire de Big Bang refactoring / refonte.
- "J'ai presque fini" pendant des mois
- Working Effectively With Legacy Code (Michael Feathers)
Comment le faire passer au niveau managerial ?
- Dire non, expliquer pourquoi, et dire comment on veut travailler ("non, mais...")
- avoir une éthique du produit
Achitecture incrémentale
- si on peut changer une partie sans augmenter la complexité
- CQRS
- UseCase
- DDD
Est-ce qu'enlever des lignes de code diminue l'entropie ?
- si c'est bien fait oui