Retour à la liste

Ca sent pas bon , Gary

15 February 2026 Modifié le 16 February 2026 Software craftsmanship 4 min de lecture

Aujourd'hui, je suis entrain de lire agile software development, et je suis sur le chapitre "Design Smells - The Odors of rotting software"

Et y'a 7 critères qui sont importants qui montrent ,pour le design choisi, que le code ne convient pas :

  1. La rigidité
  2. La fragilité
  3. Immobilisme
  4. Viscosité
  5. Complexité inutile
  6. Répetion
  7. Opacité

La rigidité

On a tous été confronté un jour ou l'autre à une mauvaise estimation du travail à faire car le changement entraine une cascade de mise à jour.

Il y a quelques années, je bossais pour des usines de pare-choc de voiture et j'assurais la maintenance du logiciel de supervision de production.

Le logiciel était un monolithe, sans aucune séparations des responsabilités : ajouter un champ sur un formulaire entrainait des mises à jour d'éléments qui utilisait l'objet mais pas le nouvel attribut. On se retrouvait a devoir mettre à jour un service non lié à l'interface.

La moindre feature se transformait en parcours du combattant pour trouver tous les impacts...SANS TU/TI/CICD. (Faites toujours des TU, par pitié!)

La fragilité

Toujours sur les pare-chocs avec cette histoire de fomulaire (l'écran m'a traumatisé) :

C'était l'écran après celui de login, l'écran de travail des opérateur.trices

Tu bougeais un champ d'un pixel, l'écran ne compilait plus. Pourquoi ? Parce que le code METIER est dépendant des champs affichés et positionnés à l'écran.

Un autre exemple, plus à l'échelle du logiciel et pas juste d'un écran, le moindre changement dans la partie "infra" (SQL) impactait la partie métier, sur du code métier qui n'avait pas de lien direct.

Immobilisme

On a envie de refactoriser, de respecter la boy scout rule...Mais c'est n'importe quoi : tout est lier , on retrouve des requêtes SQL directement sur l'appui d'un bouton , l'initilisation du service ailleurs pfouuu... Changer est trop compliqué.

Viscosité

De que j'ai compris, on distingue deux types de viscosité : il y a celle du logiciel, et celle de l'environnement. Concernant le logiciel, c'est quand respecter les principes coûte plus que faire autrement. Le but est que le design accompagne plus qu'il ne constraint. Maintenant pour l'environnement...L'IDE met 3 plombes à s'ouvrir , mais en même temps faut le faire le matin, à la pause, le midi, à la pause ... PFOUU... La compilation prends quelques minutes...Repeter à l'échelle de la journée, c'est long. C'est couteux en temps, et c'est frustrant.

Complexité inutile

Ca recoupe le principe KISS et YAGNI : Ne faits des trucs compliqués par anticipation parce que peut être y'en aura besoin. Ou parce qu'il faut gérer ce cas dans un futur proche.

Repetition ou le Ctrl+C Ctrl+V syndrome

Pour, c'est plûtot DRY comme principe, mais éviter les répétitions factoriser, mutualiser (mais pas trop, faut le faire de façon cohérence

Opacité

C'est parce que tu comprends le code maintenant, que tu le comprendras toujours dans 1 mois ou 2 : Le code doit être clair, expressif. Il doit se lire comme un livre.