Principe YAGNI, Comment écrire du code de qualité en évitant les fonctionnalités inutiles

Par Kamanga18 juin 202412 mins de lecture

Bien sûr ! Voici l'article complet, toutes sections réunies.


YAGNI : Comment écrire du code de qualité en évitant les fonctionnalités inutiles

Introduction : Qu’est-ce que YAGNI ?

Mise en situation : tu travailles sur un projet de développement, et tu te dis que ce serait une bonne idée d’anticiper certains besoins futurs. Tu décides donc d’ajouter une ou deux fonctionnalités "au cas où". Mais voilà, des mois plus tard, ces fonctionnalités ne sont toujours pas utilisées, et pire, elles compliquent la lecture et la maintenance de ton code. Cela te semble familier ?

Si c’est le cas, tu n’es pas seul. Beaucoup de développeurs tombent dans ce piège, c’est là que le principe YAGNI (You Aren’t Gonna Need It) intervient. YAGNI est un des piliers du software craftsmanship, conçu pour t’aider à éviter l'ajout de fonctionnalités inutiles. En l’appliquant correctement, tu gardes ton code simple, évolutif et sans surcharge.

Dans cet article, je vais te montrer comment appliquer YAGNI de manière pratique dans ton code, avec des exemples concrets en Java. À la fin, tu comprendras comment identifier et éviter les ajouts superflus pour écrire du code plus propre, plus rapide à tester et plus facile à maintenir.


Pourquoi appliquer YAGNI ?

Le principe de YAGNI n’est pas juste un mantra pour les puristes du code propre ; il a des avantages concrets qui impactent la qualité de ton code et la productivité de ton équipe. Voici pourquoi appliquer YAGNI peut vraiment transformer ta manière de développer :

1. Réduction de la complexité

Chaque nouvelle fonctionnalité que tu ajoutes à ton code, même si elle semble innocente, augmente la complexité globale. Cette complexité se traduit par plus de lignes de code à maintenir, des tests supplémentaires à écrire et un risque plus élevé de bugs. En évitant d'ajouter des fonctionnalités inutiles, tu simplifies ton code et le rends plus facile à comprendre pour toi et pour les autres développeurs qui le liront après toi.

2. Diminution de la dette technique

Ajouter des fonctionnalités que tu n’utiliseras peut-être jamais, c’est créer une forme de dette technique. Avec le temps, ces parties de code inutiles peuvent poser des problèmes : elles deviennent obsolètes, difficiles à maintenir ou doivent être adaptées pour fonctionner avec d’autres changements. En appliquant YAGNI, tu évites d'accumuler cette dette, et tu restes concentré sur les fonctionnalités réellement nécessaires.

3. Gagner du temps et des ressources

Quand tu écris moins de code, tu gagnes du temps. Ce n’est pas seulement le temps passé à écrire, mais aussi celui passé à tester, déboguer et maintenir ce code. Cela permet à toi et à ton équipe de vous concentrer sur des fonctionnalités qui apportent une réelle valeur au produit final, plutôt que de perdre du temps sur des éléments hypothétiques.

4. Favoriser la flexibilité

En te concentrant uniquement sur ce qui est nécessaire, tu t'assures que ton code est plus modulaire et prêt à évoluer. Un code simple est plus facile à adapter lorsqu’un nouveau besoin se présente réellement. YAGNI t'encourage à ne pas anticiper les besoins futurs, car ces besoins changent souvent avec le temps. En gardant ton code minimaliste, tu seras plus agile face aux demandes imprévues.


Comment identifier une fonctionnalité inutile ?

L’une des plus grandes difficultés dans l’application du principe YAGNI est de savoir si une fonctionnalité est réellement nécessaire ou non. La tentation d’ajouter des éléments "au cas où" peut être forte, mais voici quelques critères pour t’aider à identifier ce qui est superflu.

1. Demande immédiate ou hypothétique ?

Un des indicateurs les plus simples : est-ce que cette fonctionnalité répond à un besoin immédiat ? Si la réponse est non et qu'elle est seulement là pour anticiper un besoin futur potentiel, il est probable que tu n’en auras pas besoin. YAGNI te pousse à implémenter uniquement ce qui est nécessaire aujourd'hui. Si un jour ce besoin se présente, tu pourras toujours l'ajouter au bon moment.

2. Est-ce que c’est nécessaire pour la fonctionnalité actuelle ?

Si cette nouvelle fonctionnalité n’est pas essentielle pour le fonctionnement de ce que tu es en train de développer, alors elle est peut-être inutile. Pose-toi cette question : "Est-ce que mon application marcherait toujours correctement sans cette fonctionnalité ?" Si la réponse est oui, alors il est probablement sage de la laisser de côté pour l’instant.

3. Est-ce que ça complique le code ?

Un autre bon indicateur est de voir si cette nouvelle fonctionnalité ajoute de la complexité au code existant. Si elle rend ton code plus difficile à lire, à tester ou à maintenir, c'est un signe clair qu'elle pourrait être inutile. Souviens-toi que le code simple est toujours plus facile à faire évoluer, et YAGNI t’encourage à garder ton code aussi léger que possible.

4. Est-ce que c’est une demande externe ou interne ?

Parfois, la pression vient de l’extérieur – un client, un supérieur ou un collègue peut insister pour ajouter des fonctionnalités "juste au cas où". Dans ces situations, il est important de bien évaluer si la demande est justifiée ou si elle repose sur des hypothèses. Expliquer les avantages du principe YAGNI peut aussi aider à éviter d’ajouter des fonctionnalités inutiles.

Exemples concrets en Java

Prenons un exemple simple en Java où l’on pourrait être tenté d’ajouter une fonctionnalité inutile :

// Exemple où une fonctionnalité inutile est ajoutée
public class User {
    private String name;
    private int age;
    private String address; // Cette information n'est pas encore utilisée

    public User(String name, int age) {
        this.name = name;
        this.age = age;
        // On pourrait être tenté d'ajouter l'adresse dès maintenant, mais YAGNI !
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
    
    // On pourrait ajouter un getter pour l'adresse ici, mais ça serait prématuré.
}

Dans cet exemple, l’attribut address est inutile tant que le programme n’en a pas besoin. Selon YAGNI, on ne l'ajoute pas avant d'avoir une demande précise pour cette fonctionnalité.


Bonnes pratiques pour appliquer YAGNI en Java

Appliquer YAGNI de manière efficace demande de la discipline et une certaine maîtrise des principes de base du développement. Voici quelques bonnes pratiques qui te permettront d’intégrer YAGNI dans ton quotidien, en particulier lorsque tu écris du code Java.

1. Utilise les tests pour guider ton développement

L’une des meilleures manières de ne pas anticiper inutilement est d’adopter une approche Test-Driven Development (TDD). En TDD, tu écris d’abord un test pour la fonctionnalité spécifique que tu veux implémenter, puis tu écris juste assez de code pour passer ce test. Cela t’oblige à te concentrer uniquement sur ce qui est nécessaire pour faire fonctionner ton application.

Exemple en Java :

@Test
public void testAddUser() {
    User user = new User("Alice", 30);
    assertEquals("Alice", user.getName());
    assertEquals(30, user.getAge());
}

Avec ce test, on se concentre uniquement sur l'ajout de l'utilisateur avec un nom et un âge. Tant que l’on ne passe pas de test nécessitant l’adresse, il est inutile d’ajouter un attribut address à la classe User.

2. Évite de généraliser trop tôt

Un autre piège commun est de vouloir tout de suite rendre ton code trop générique ou flexible. Par exemple, tu pourrais penser qu’une méthode pourrait être réutilisée plus tard et vouloir la rendre paramétrable. Mais en réalité, si cette flexibilité n’est pas nécessaire maintenant, elle pourrait ne jamais l’être.

Exemple à éviter :

public class MathOperations {
    // On pourrait être tenté de rendre cette méthode très générique
    public int multiply(int a, int b, boolean absoluteValues) {
        if (absoluteValues) {
            return Math.abs(a) * Math.abs(b);
        } else {
            return a * b;
        }
    }
}

Cette méthode introduit de la complexité inutile (avec le paramètre absoluteValues) si ton programme n'a besoin que de multiplier des nombres sans se préoccuper de leur signe. La solution YAGNI serait de garder la méthode simple :

public class MathOperations {
    public int multiply(int a, int b) {
        return a * b;
    }
}

3. Refactorise régulièrement ton code

Refactoriser régulièrement te permet de retirer les fonctionnalités qui sont devenues inutiles au fil du temps. Parfois, un projet évolue et certaines parties du code, ajoutées dans l'anticipation de besoins futurs, ne sont jamais utilisées. Il est essentiel d’avoir un code propre et minimal pour faciliter les modifications et éviter que du code non nécessaire ne s'accumule.

4. Collabore avec ton équipe sur les fonctionnalités

Travailler en équipe demande de la communication, surtout en ce qui concerne la prise de décision sur les fonctionnalités. Si quelqu'un propose d’ajouter

une nouvelle fonctionnalité, assure-toi qu'il existe un besoin clair et immédiat. Si c'est pour anticiper des besoins futurs, demande si ces besoins sont confirmés ou s'il s'agit simplement d'une spéculation.

Exemple de réflexion d’équipe :

"Est-ce que cette fonctionnalité sera utilisée par les utilisateurs actuels ? Sinon, on pourrait la développer plus tard si un besoin réel émerge."

5. Ne pas coder pour des fonctionnalités hypothétiques

Souvent, on se dit que certaines fonctionnalités seront utiles dans le futur, mais bien souvent, ces hypothèses sont fausses. Pour appliquer YAGNI, il est important de coder uniquement pour répondre aux exigences actuelles du projet. Les fonctionnalités futures seront ajoutées en temps voulu, lorsque les besoins seront confirmés.


Erreurs courantes et objections liées à YAGNI

Même si le principe YAGNI paraît simple en théorie, de nombreuses erreurs sont commises lorsqu'il est mis en pratique. De plus, certains développeurs expriment des réticences à l'appliquer strictement. Examinons quelques erreurs courantes et les objections les plus fréquentes que l’on entend au sujet de YAGNI.

1. Erreur : Préparer le code pour des scénarios hypothétiques

L’une des erreurs les plus répandues est de croire que l’ajout d’une fonctionnalité "juste au cas où" est une bonne pratique. Cela part souvent d’une bonne intention, mais cela mène presque toujours à une complexité inutile. En réalité, la majorité des "cas potentiels" anticipés ne se présentent jamais.

Exemple :

Imaginons que tu ajoutes un traitement pour gérer des devises dans une application qui ne fait encore que des transactions en euros. En supposant que, peut-être un jour, l’application gérera plusieurs devises, tu commences à ajouter du code pour les conversions monétaires. Pourtant, si ce besoin ne devient jamais concret, tu te retrouves avec du code qui alourdit ton application sans apporter de valeur.

2. Erreur : Ne pas s’adapter à l’évolution des besoins

Certaines personnes confondent YAGNI avec un refus d’anticiper totalement. YAGNI ne signifie pas que tu ne devrais jamais changer ou adapter ton code aux nouvelles exigences. Il s’agit plutôt de ne pas écrire du code en prévision d’un besoin qui pourrait ne jamais exister. Si un nouveau besoin émerge effectivement, c’est alors le bon moment pour l’ajouter.

Exemple :

Si, dans ton application, un nouveau client demande une fonctionnalité spécifique, alors il est tout à fait légitime de l’ajouter. L’important est de s’assurer que cette demande est confirmée, et non basée sur des spéculations.

3. Objection : "Si je ne l’ajoute pas maintenant, je devrai tout refaire plus tard"

Cette peur est fréquente, surtout chez les développeurs qui souhaitent éviter de retourner sur des morceaux de code plus tard. Pourtant, YAGNI t’encourage à ne pas surcharger ton code en essayant d'anticiper tous les futurs possibles. Quand un besoin précis survient, tu pourras y répondre avec une solution adaptée à la situation actuelle, et souvent cela sera bien plus efficace que si tu avais tenté d’anticiper toutes les variables dès le départ.

4. Objection : "Mon client ou mon chef veut toujours plus de fonctionnalités"

Il arrive que des clients ou des supérieurs souhaitent des fonctionnalités supplémentaires "au cas où", sans vraiment savoir s’ils en auront besoin. Dans ce cas, il est important d’expliquer pourquoi YAGNI est avantageux, à la fois pour réduire la complexité du produit et pour économiser du temps et des ressources. L’argument est simple : en évitant d’ajouter des fonctionnalités inutiles, tu réduis les coûts de développement à court terme et tu gardes le code plus flexible pour l'avenir.

5. Erreur : Se limiter par peur de manquer d'anticipation

À l’inverse, certains développeurs peuvent mal comprendre YAGNI et éviter de préparer le code à des extensions évidentes, même lorsque le besoin futur est bien identifié. YAGNI ne signifie pas de complètement ignorer les futurs possibles, mais de les traiter uniquement lorsque le besoin est avéré. Si tu sais qu’une fonctionnalité sera nécessaire, ne pas l’implémenter pourrait être contre-productif. L’idée est d’avoir la souplesse de rajouter des fonctionnalités en temps voulu, pas d’éviter de faire évoluer le produit.


FAQ : Réponses aux questions fréquentes sur YAGNI

1. Qu’est-ce que YAGNI ?

YAGNI signifie "You Aren’t Gonna Need It" et fait partie des principes de software craftsmanship. Il encourage les développeurs à ne pas ajouter de fonctionnalités inutiles ou prématurées dans leur code, en se concentrant uniquement sur les besoins actuels plutôt que sur des hypothèses de besoins futurs.

2. Quand devrais-je appliquer YAGNI ?

Tu devrais appliquer YAGNI dès que tu te demandes si une fonctionnalité que tu es en train de coder sera réellement utilisée ou si tu l’ajoutes juste par anticipation. Si cette fonctionnalité ne répond pas à un besoin immédiat, elle est probablement superflue.

3. Comment puis-je expliquer YAGNI à mon équipe ou à mon client ?

La meilleure façon d’expliquer YAGNI est de montrer comment ce principe aide à maintenir un code simple, évolutif, et moins coûteux à long terme. Si tu ajoutes des fonctionnalités hypothétiques, tu augmentes la complexité, ce qui rend la maintenance plus difficile et coûteuse. En restant focalisé sur ce qui est nécessaire, tu économises du temps et des ressources.

4. Et si j’ai vraiment besoin de cette fonctionnalité plus tard ?

YAGNI ne t’empêche pas d’ajouter des fonctionnalités quand elles deviennent réellement nécessaires. Le principe encourage simplement à ne pas anticiper des besoins incertains. Si un besoin futur se concrétise, tu pourras ajouter la fonctionnalité à ce moment-là, avec une meilleure compréhension des exigences.

5. YAGNI est-il compatible avec les méthodes agiles ?

Absolument. YAGNI s’intègre parfaitement dans les méthodologies agiles qui mettent l’accent sur la livraison rapide de la valeur et l’adaptation aux besoins changeants. En te concentrant sur les besoins actuels et en livrant des incréments de valeur fonctionnelle, tu réponds aux exigences du client sans surcharger le produit avec des fonctionnalités inutiles.

6. Comment éviter de coder pour des scénarios hypothétiques ?

La meilleure manière est de t’en tenir strictement aux exigences du projet et d’utiliser des pratiques comme le Test-Driven Development (TDD). En n’écrivant que le code nécessaire pour faire passer les tests, tu restes focalisé sur l’essentiel sans t’égarer dans des fonctionnalités anticipées.

7. Quels sont les risques de ne pas appliquer YAGNI ?

Ne pas appliquer YAGNI conduit à un code plus complexe et plus difficile à maintenir. Cela peut également augmenter la dette technique, car les fonctionnalités ajoutées prématurément peuvent devenir obsolètes, ou être mal adaptées lorsque les véritables besoins émergent.


Conclusion

Le principe YAGNI est un excellent guide pour garder ton code simple, propre et focalisé sur ce qui compte réellement : répondre aux besoins immédiats de ton projet. En l'appliquant correctement, tu éviteras d’ajouter des fonctionnalités inutiles qui compliquent la maintenance et augmentent la dette technique. J'espère que cet article et les exemples en Java t'aideront à mieux intégrer YAGNI dans tes pratiques de développement au quotidien.


Rédigé par Kamanga

Expert IT avec 25 ans d'expérience en développement logiciel, diplômé EPITECH et MBA. Spécialisé en software craftsmanship, gestion du changement, stratégie, direction des systèmes d'information, coaching et certifié en agilité.

Copyright © 2024
 Kamanga
  Powered by bloggrify