The .Net frog

Pour ce premier billet d'une longue série (je l'espère du moins) sur les bonnes pratiques de développement, les méthodes agiles, et les valeurs défendues par Alt.Net, je vous propose de vous faire (re)découvrir 3 acronymes qu'il convient d'appliquer quotidiennement.

DRY - Don't Repeat Yourself:
L'acronyme DRY se traduit en français par "Ne vous répétez pas". Autrement dit, cet acronyme rappelle qu'il ne faut pas avoir des lignes de code identiques dupliquées à plusieurs endroits. En effet, les blocs de codes dupliqués devrait être déplacés dans une fonction ou dans une classe afin de pouvoir être réutilisables partout ailleurs. DRY permet donc une plus grande abstraction et diminue la complexité. La maintenabilité de l'application est aussi améliorée dans le sens ou les modifications du code n'auront plus à être reporté à différents endroits.

KISS - Keep It Simple, Stupid:
En développement, il est simple de faire compliqué et compliqué de faire simple! KISS, qui se traduit par "Gardez le code simple, stupide" rappelle ce grand principe. Malheureusement, il n'y a pas de recette miracle pour appliquer KISS. Il faut par exemple garder un code explicite, un niveau d'abstraction correct, ne pas optimiser prématurément, utiliser des patterns reconnus plutôt que de réinventer la roue, utiliser la composition plutôt que l'héritage pour réduire la taille des classes et promouvoir la réutilisation (DRY!), ou encore adopter la "programmation basé sur les interfaces" et l'inversion de contrôle. Evidemment, cette liste est non exhaustive et chaque point mériterait son propre billet!

YAGNI - You're Ain't Gonna Need It!:
YAGNI, ou, en français, "Vous n'allez pas en avoir besoin!" est une pratique très chére aux méthodes agiles. Le but avoué de YAGNI est d'éviter de développer quoique ce soit qui ne soit pas nécessaire maintenant. Quelques exemples:

• il ne sert à rien de développer des fonctionnalités qui n'ont pas été demandées par les utilisateurs, sous peine de faire quelque chose de complètement inutile et de perdre son temps.
• Attention de ne pas inventer quelque chose d'extrèmement puissant/modulaire/extensible/(ajouter votre mot ici) par rapport au besoin (KISS!). Attendez que le besoin se manifeste réellement pour commencer à développer quelque chose de plus complexe. Si vous le faites trop tôt, il est tout à fait possible que les priorités changent en cours de route et que tout soit rendu bancal par de nouveaux développements.
• N'optimisez pas prématurément, sous peine de passer des heures à gagner 100ms sur une partie du système qui sera en fin de compte modifiée 2 semaines plus tard.

En résumé: DRY! KISS! YAGNI!