YAGNI ou AYRNGNI, là est la question

Programmer est un passe-temps. Développer du code facile à maintenir et à faire évoluer est une profession. À la seconde où un programmeur décide de prendre sa carrière en main et à s’informer sur cette science infuse qu’est le code propre, on tombe rapidement dans une spirale infernale de principes de programmation à l’acronyme douteux. Après avoir couvert les principes SOLID, que je vous invite à lire et relire, aujourd’hui, on va regarder YAGNI.

You aren’t gonna need it!

You Aren’t Gonna Need It (t’en auras pas besoin) est un mantra de la programmation extreme. En tant que dev, on fait des hypothèses sur des fonctionnalités de notre application pour essayer d’être à l’épreuve du futur et avoir plus de facilité à faire évoluer le système. C’est donc à cette étape de YAGNI prend tout son sens.

Comment on applique YAGNI ?

Supposons un cas bien précis. Vous avez un backend avec un langage verbeux comme Java et une base de données Oracle. Vous travaillez sur une application qui gère des clients pour une entreprise et votre client (ou boss!) vous demande d’ajouter une liste d’attente pour les nouveaux clients. Un client est soit dans la liste d’attente, soit dans liste régulière. Vous avez donc plusieurs solutions pour régler ce problème :

1. Solution simple, vous gardez un flag InWaitList dans la table des clients.
   1. Si le flag est à false, le client n’est pas dans la liste et vice-versa.
2. Solution intermédiaire, vous gardez une liste de statuts qui ont le flag de la solution 1. On associe ensuite un statut avec un client (1 – N).
   1. Les clients ayant un statut considéré comme dans la liste d’attente sont dans la liste d’attente. Les autres non.
3. Solution totale, vous garder la même liste de statut que la solution 2, mais vous faites un lien N – N avec les clients. Dans la table de jonction, vous gardez la date de status.
   1. Le client est dans la liste d’attente si le dernier statut qu’il a est considéré comme dans la liste d’attente. Les autre, non.

Si vous demandez au client, il vous répondra qu’un client ne peut qu’être dans la liste d’attente ou pas dans la liste d’attente. Donc pas besoin de se casser le bessique (casser la tête pour nos amis européens, bessique == bicycle).

Par contre, toi, comme dev, tu le sais très bien que faire la solution 1 fonctionne. Par contre, tu sais aussi que faire la solution 1, puis la défaire et refaire la solution 3, incluant les tests unitaires, ça représente pratiquement le triple du temps de développement que de faire la solution 3 immédiatement.

On serait tenté ici de se poser la question : « Est-ce que je vais vraiment avoir besoin de plusieurs statuts pour ma liste d’attente? »

Et il est là le piège… Poser la question, c’est avoir deux options possibles. Alors qu’en vrai… YAGNI. Fais-le pas. Ou encore KISS (Keep It Simple, Stupid, ou garde ça simple et stupide). N’ajoute pas de complexité pour rien.

Et AYRNGNI…?

(dis-le 5 fois à haute voix le plus vite possible)

Ok ok… Celui-là existe pas, c’était juste pour le titre! AYRNGNI  signifie Are You Really NOT Gonna Need It (ou allez-vous vraiment ne pas en avoir besoin). Ici, c’est pour apporter une légère nuance aux développeurs plus jeunes (pas toi Roger! Toi t’es déjà un sénior expert PL-1).

Tous les principes de programmation sont faits pour être brisé.

Avant de te rendre dans les commentaires pour me dire que j’ai tord, laisse-moi t’expliquer…

YAGNI peut être brisé lorsque nécessaire dans ce sens où l’application de ces principes ne doit absolument pas empêcher l’évolutivité du système. En reprenant l’exemple de la liste d’attente, on peut s’imaginer que le client, après avoir testé, se rend compte qu’il doit aussi pouvoir traiter ses clients dans la liste d’attente. Un personne doit pouvoir analyser le dossier du client et l’accepter ou non. Dans le cas où il l’accepte, le client s’en va dans la liste régulière. Dans le cas où il est refusé, il disparaît complètement de la liste régulière et de la liste d’attente.

Merde… mon flag ne fait plus la job. Je dois ajouter deux nouvelles tables, entités, leurs services d’affaires et tous les tests unitaires. Finalement, l’estimation initiale de « juste ajouter un flag » ne tient plus non plus.

Donc je fais quoi ?

Pas simple. L’expérience peut aider à répondre à la question, parce que c’est vrai qu’on ne veut pas développer des fonctionnalités pour rien, mais on ne veut pas non plus développer une fonctionnalité qui ne fera pas la job à long terme et qui va faire gonfler le coût de développement.

Le premier conseil que je pourrais vous donner, c’est de poser toutes les questions nécessaires à bien comprendre le requis. Puis, vous devez tendre l’oreille pour les mots qui devraient vous sonner des cloches, soit quand vous les dites, soit quand vous les entendez : « C’est JUSTE de faire… », « Tant qu’à y être », « Tant qu’à être dedans », « Au lieu de faire […] on pourrait […] », etc..

Comme dernier et, selon moi, le plus important conseils, c’est de comprendre comme ça fonctionne. Développer une fonctionnalité a un coût. Dans ces coûts, on y retrouve évidemment nos salaires, les licenses, etc.. On peut faire très simple en disant que ça coûte grosso-modo 800 $ (CAD) / jour / personne. La fonctionnalité développée doit donc impérativement produire un retour sur l’investissement (ROI). Par exemple, si on dit que l’adjointe qui gère la liste des clients de votre client et qui utilise la fonctionnalité, madame Ginette, sauve 10 minutes chaque fois qu’elle cherche un client, qu’elle cherche 2 clients par heures à 20 $ /h (son salaire), on se retrouve à dire que la fonctionnalité va rapporter ~ 53 $ / jour en économie de salaire.

On peut donc ici affirmer avec certitude que si on a une solution simple, on arrivera à rembourser les coûts de développement assez rapidement. Par contre, si on s’embarque dans une solution de 20 j / p, on va quand même rembourser les coûts de développement, mais ça va être beaucoup plus long.

Conclusion

Pour résumer si vous devez appliquer YAGNI ou pas :

1. Calculez un ROI approximatif. Ça doit par prendre plus de 5 minutes, allez-y à peu près.
2. Posez toutes les questions pour être sûr de bien comprendre. Même si vous avez l’impression d’être fatiguant! C’est moins fatiguant de poser la même question plusieurs fois que de recoder le même module plusieurs fois.
3. Identifiez les mots clés : « C’est JUSTE de faire… », « Tant qu’à y être », « Tant qu’à être dedans », « Au lieu de faire […] on pourrait […] », etc..

Merci d’avoir tout lu 🙂 Hésitez pas à partager avec vos collègues et amis. Chaque partage est l’équivalent d’une paie pour nous. T’as d’autres trucs? Je veux les savoir en commentaires 😀

Cheers!

60

SHARES

Partager sur Facebook

Partager sur Twitter

Suivez-nous!

Share

Share

Share

Share

Share