Dans les projets de développement, le problème de la redondance du code va se poser régulièrement. Les développeurs juniors dupliquent les codes. Pour normaliser cette lutte, le DRY a été créé. C’est l’acronyme de don’t repeat yourself (ne vous répétez pas).
Quelle est l’origine du DRY ?
Comme mentionné ci-dessus, il existe un grand nombre de projets de développement qui contiennent des répétitions inutiles de morceaux de code. Veuillez noter qu’il s’agit d’un problème important. Surtout, pendant l’évolution du projet et la phase de maintenance.
Sujet a lire : Les facteurs clés de succès pour une stratégie d'enrichissement de données
Si vous devez apporter des modifications à un bloc de code et qu’il est déjà marqué trois fois de suite dans le projet, vous devez le modifier trois fois également. Sinon, si vous décidez de ne pas le modifier à un moment donné, cela devient un gros problème. Par exemple, cela peut provoquer des bugs en cascade.
Quelles sont les raisons pour lesquelles vous ne devriez pas mettre en œuvre du DRY ?
De toute évidence, DRY ne devrait pas être mis en œuvre à tout moment. Certes, il vous offre d’obtenir des codes plus maintenables et plus propres avec peu d’objectifs. Mais, vous devriez l’éviter !
A voir aussi : Nantes, choisissez l'excellence en expertise comptable
Pensez à l’avenir lorsque vous développez une fonctionnalité. Certaines personnes se concentrent davantage sur la simplification extrême lorsqu’elles écrivent du code.
Dès lors, vous devez appliquer le DRY à la phase de refactoring du code. Évitez de l’appliquer pendant la phase d’écriture. Gardez à l’esprit que la majorité du code doit être simplifiée dès le début.
Les règles définies en interne sont une autre source de surutilisation du DRY. C’est précisément le cas des CTO. Ils veulent parfois avoir un code hyper simplifié dès le début du projet. Nous vous recommandons de garder une certaine flexibilité.
