Ce sont trois principes auxquels tout développeur devrait faire attention, car ils concernent le code propre. Dans cet article, nous allons comprendre ce que chacun d’entre eux signifie.

Principe DDRY

DRY signifie Don’t Repeat Yourself. Dans le livre ‘The Pragmatic Programmer’, nous pouvons voir cette définition de DRY:

Chaque élément de connaissance doit avoir une représentation unique, non ambiguë et faisant autorité dans un système.

Cela signifie que vous ne devriez pas avoir de code dupliqué. Il est plus facile de maintenir un code qui n’est qu’à un seul endroit, parce que si vous avez besoin de changer quelque chose dans le code, vous avez juste besoin de changer à un seul endroit. En outre, si vous avez le même code à deux ou plusieurs endroits, le risque que ce code devienne différent au fil du temps est élevé, et lorsque cela se produit, cela devient un moyen facile d’introduire des bogues dans votre système. Le code dupliqué rend également le code plus complexe et inutilement plus grand.

Vous ne devriez pas non plus écrire du code ambigu. Vos classes, vos variables, vos fonctions, elles doivent avoir un nom spécifique, et leur nom doit correspondre à leur responsabilité. Si vous avez une fonction, vous devriez savoir ce que fait la fonction en lisant simplement son nom, sans avoir besoin de lire le code à l’intérieur.

Dans le livre ‘The Pragmatic Programmer’, nous pouvons également voir que :

DRY concerne la duplication de la connaissance, de l’intention. Il s’agit d’exprimer
la même chose à deux endroits différents, éventuellement de deux manières totalement différentes

Cela signifie qu’il ne s’agit pas seulement de copier et coller du code – oui, cela est également inclus – mais cela va au-delà. Il s’agit aussi d’avoir un code différent qui fait la même chose. Peut-être que vous pouvez avoir un code différent à deux ou plusieurs endroits, mais ils font la même chose de différentes manières, cela doit également être évité.

Principe KISS

KISS est un acronyme pour Keep It Simple, Stupid. Ce principe dit à propos de faire votre code simple. Vous devez éviter toute complexité inutile. Un code simple c’est plus facile à maintenir et plus facile à comprendre.

Vous pouvez appliquer ce principe dans la conception et dans l’implémentation du code. Vous devriez éliminer le code dupliqué, devrait supprimer les fonctionnalités inutiles, ne pas utiliser des variables et des méthodes inutiles, utiliser des noms pour les variables et les méthodes qui a du sens et correspond à leurs responsabilités, et toujours quand c’est possible, suivre les normes connues de développement de code. Vous devriez également séparer les responsabilités de vos classes et les responsabilités des couches du projet.

Parfois, vous n’avez pas besoin de mettre en œuvre quelque chose de nouveau pour assister à vos besoins, vous pouvez simplement utiliser les fonctionnalités du langage de programmation que vous utilisez. Pour cela, il est bon que vous connaissiez les fonctionnalités du langage de programmation avec lequel vous travaillez.

Si vous travaillez dans un code qu’il est déjà implémenté, et que vous voyez quelque chose qui n’est pas nécessaire ou qui pourrait être plus simple, vous devriez envisager de le refactorer.

Principe YAGNI

YAGNI signifie You Ain’t Gonna Need It. C’est un principe de la méthodologie de développement logiciel d’Extreme Programming (XP). Ce principe dit que vous ne devez pas créer de fonctionnalités qui ne sont pas vraiment nécessaires.

Ce principe est similaire au principe KISS, une fois que les deux visent une solution plus simple. La différence entre eux c’est que YAGNI se concentre sur la suppression des fonctionnalités et de la logique inutiles, et KISS se concentre sur la complexité.

Ron Jeffries, l’un des cofondateurs de l’XP, a dit une fois:

Implémentez toujours les choses quand vous en avez réellement besoin, jamais quand vous prévoyez juste que vous en avez besoin.

Cela signifie que vous ne devriez pas implémenter une fonctionnalité juste parce que vous pensez que vous pourriez en avoir besoin un jour, mais l’implémenter juste quand vous en avez vraiment besoin. En faisant cela, vous éviterez de passer du temps avec des implémentations qui n’étaient même pas nécessaires, et peut-être ne seront jamais utilisées.

Conclusion

Suivre ces principes, vous permettra d’écrire un meilleur code. Rappelez-vous qu’un code propre, il est plus facile à main, plus facile à comprendre et pour sûr, il permettra d’économiser votre temps lorsque vous avez besoin de changer ou de mettre en œuvre quelque chose. Évitez d’utiliser du code dupliqué, essayez de garder votre code aussi simple que possible, et n’implémentez des fonctionnalités que lorsque c’est vraiment nécessaire.