Blog
📋 Fiche pratique design bonnes pratiques

KISS, DRY, YAGNI

Trois acronymes fondamentaux pour garder un code simple, sans répétition et sans fonctionnalités inutiles - et les appliquer au-delà du code.

DRY
Don't Repeat Yourself
Ne dupliquer ni le code, ni les tâches.
YAGNI
You Aren't Gonna Need It
Ne développer que ce qui est nécessaire maintenant.
KISS
Keep It Simple, Stupid
La simplicité facilite la lecture, la maintenance et l'évolution.
DRY

Don't Repeat Yourself

Ne vous répétez pas

DRY invite à éviter la duplication de code. Un bloc de code écrit plusieurs fois, ou très similaire d'un endroit à l'autre, doit être extrait dans une fonction centralisée et réutilisable. Ce principe s'applique aussi aux processus et tâches manuelles répétitives - les automatiser, c'est aussi ne plus se répéter.
Idée clé Si vous faites régulièrement la même chose manuellement, il est probablement temps d'automatiser. Ne vous répétez pas - ni dans le code, ni dans vos processus.
📖 Exemple concret - Sauvegarde Trello
Au lieu d'exporter manuellement et irrégulièrement des tableaux Trello au format JSON, mise en place d'un script automatisé via cron Linux s'appuyant sur l'API Trello. Une sauvegarde quotidienne sans intervention, et un script de restauration en cas de besoin. Plus besoin d'y penser.

Don't blame the people, blame the process.

- Culture Kanban / DevOps

À retenir

  • Repérer les blocs de code identiques ou très similaires
  • Les extraire dans une fonction réutilisable et centralisée
  • Appliquer aussi aux tâches manuelles répétitives → automatiser
  • Une modification à un seul endroit = moins de bugs, moins d'oublis
⚠ Anti-pattern

Copier-coller un bloc de code en le modifiant légèrement. Si le comportement change un jour, chaque occurrence devra être mise à jour - et vous en oublierez une.

YAGNI

You Aren't Gonna Need It

Vous n'en aurez pas besoin

YAGNI encourage à ne pas ajouter de fonctionnalités dont l'utilité n'est pas avérée. Développer par anticipation augmente les coûts, complexifie le système et n'apporte aucune valeur aux utilisateurs. Les problèmes futurs hypothétiques se traitent quand ils deviennent prioritaires.
Idée clé L'architecture doit rester évolutive et flexible, sans conduire à des développements anticipatifs inutiles. Concentrez-vous sur les besoins réels et actuels - maximisez la valeur livrée.
📖 Exemple - Flux de données enrichi
En réunion, débat sur la mise en place d'un nouveau flux enrichi de données. Le flux actuel suffit à automatiser toute la chaîne de traitement, les données enrichies ne répondent à aucun besoin client. Pourquoi implémenter un flux plus complexe sans usage identifié ?
📖 Exemple - Module de transport interne
Un responsable envisageait de développer un module de transport de flux en interne, alors que des partenaires spécialisés couvrent déjà ce besoin. Pourquoi créer quelque chose de potentiellement moins performant quand un partenaire répond déjà au besoin ?

À retenir

  • Ne développer que ce qui répond à un besoin identifié et actuel
  • Évaluer si un partenaire ou outil existant ne couvre pas déjà le besoin
  • Les problèmes futurs hypothétiques se traitent quand ils deviennent prioritaires
  • Chaque fonctionnalité non livrée est du temps disponible pour la valeur réelle
⚠ Anti-pattern

Développer par anticipation "au cas où on en aurait besoin un jour". Cela consomme du temps, ajoute de la complexité et génère du code à maintenir sans retour sur investissement.

KISS

Keep It Simple, Stupid

Garde le simple

KISS invite à ne pas rendre le code plus complexe que nécessaire. Ce qui est simple à lire est simple à comprendre, à maintenir et à faire évoluer. À l'inverse, un code trop complexe - le fameux code spaghetti - devient un fardeau où le moindre changement risque de tout casser.
Idée clé La simplicité n'est pas une facilité - c'est un investissement. Un code simple aujourd'hui, c'est des heures économisées à chaque future maintenance ou évolution.
🍝 Le code spaghetti - ce qu'il faut éviter
Un code mal découpé qui s'entremêle, aux responsabilités floues et aux dépendances enchevêtrées. Le moindre changement demande de comprendre l'ensemble du système. Chaque modification risque de provoquer des régressions imprévues. Le temps de développement explose à mesure que la base de code vieillit.

À retenir

  • Écrire pour être lu - par un collègue, ou par soi-même dans 6 mois
  • Découper en fonctions claires avec une seule responsabilité
  • Éviter les abstractions prématurées et les sur-architecturations
  • Un code simple est plus facile à tester, à déboguer et à faire évoluer
⚠ Anti-pattern

Le code spaghetti : fonctions qui font trop de choses, logique dispersée, dépendances croisées. Impossible à démêler sans tout casser. S'accumule progressivement si on n'y prête pas attention dès le départ.

Les trois principes ensemble

Appliqués conjointement, DRY, YAGNI et KISS se renforcent mutuellement. DRY évite la duplication, YAGNI évite le superflu, KISS évite la complexité. Un code qui respecte ces trois principes est un code qui dure, se maintient facilement et évolue sereinement.

Ce ne sont pas des règles rigides - ce sont des boussoles. L'objectif est de les garder en tête à chaque décision de design pour orienter naturellement vers plus de clarté et de valeur.

DRY - pas de duplication YAGNI - pas de superflu KISS - pas de complexité inutile