Principes, patterns et bonnes pratiques

Ici nous allons énumérer un certain nombre de principes et de bonnes pratiques qui ont été pensées et validées par l’ensemble du monde informatique.

DRY Don’t repeat yourself

Ne vous répétez pas (don’t repeat yourself en anglais, aussi désigné par l’acronyme DRY) est une philosophie en programmation informatique consistant à éviter la redondance de code au travers de l’ensemble d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière.

KISS Keept is simple , stupid

Le principe KISS, Keep it simple, stupid (en français, mot à mot : « garde ça simple, idiot », dans le sens de « ne complique pas les choses ») ou bien Keep it stupid simple (en français, « garde ça super simple », avec l’idée que « même un idiot pourrait comprendre »), est une ligne directrice de conception qui préconise la simplicité dans la conception et que toute complexité non indispensable devrait être évitée dans toute la mesure du possible. Ce principe est appliqué dans un grand nombre de disciplines telles que le développement logiciel, l’animation, le journalisme, la photographie, l’ingénierie, l’aviation et la planification stratégique.

Il est important de noter que le principe KISS proscrit les seules complexités non indispensables. Paradoxalement, tenter d’utiliser des moyens simples pour résoudre un problème complexe peut conduire à une complexité encore plus grande. Il s’agit d’un écueil classique auquel peut conduire une application trop naïve du principe KISS.

La complexité, souvent utile pour assurer de bonnes performances, est en effet elle-même une source de coûts de conception et de maintenance, ainsi qu’une source potentielle d’erreurs. L’idée est de ne pas optimiser quoi que ce soit avant de maîtriser totalement une version simple de ce que l’on crée. Dans le produit fini, la simplicité d’usage, même au prix du renoncement à quelques fonctionnalités, est aussi un moyen de séduire l’utilisateur qui maîtrisera pour sa part l’usage du produit.

YAGNI You ain’t gonna need it

YAGNI (anglicisme, acronyme anglais de « you ain’t gonna need it », qui peut se traduire par « vous n’en aurez pas besoin ») est un principe d’extreme programming qui déclare que les programmeurs ne devraient pas ajouter de fonctionnalité à un logiciel tant que celle-ci n’est pas absolument nécessaire.

Cela induit également que garder du code en commentaire « au cas ou » n’est pas recommandé.

KBTIF Keep business terms in french

En effet, nous sommes tentés de tout traduire dans un soucis d’uniformiser la langue mais certains concepts inhérents à un métier risquent d’être perdus ou confus si on les traduit.
C’est un concept fort qui est compréhensible en tant que tel.

S.O.L.I.D.

-Le S correspond à « Single Responsibility » qui se traduit par une seule responsabilité. Ce principe implique que votre code au sein d’une classe ne doit avoir qu’une seule responsabilité, qu’un seul type de tâche à effectuer. Si vous prenez conscience que 2 tâches différentes sont effectuées, posez-vous la question de savoir si vous devez scinder votre classe en deux ou non.

-Le O correspond à « Open / Close » qui se traduit par… Ouvrir / Fermer ! La raison de ce principe est très simple, votre classe doit-être ouverte à une extension/mise à jour, mais doit-être fermée pour toutes modifications. Cette méthode permet d’éviter la régression suite à l’ajout de nouvelles fonctionnalités. Bien sûr qu’il peut y avoir des cas ou la modification est indispensable comme la résolution d’un bug, etc. Mais ce principe invite à le faire le moins possible.

-Le L correspond à « Liskov Substitution » qui se traduit par substitution de Liskov. Juste pour information complémentaire, Liskov, de son prénom Barbara est une informaticienne de renom (prix Turing, équivalent du Nobel) qui a évoqué ce principe au début des années 90. Ce principe stipule d’une manière simplifiée, qu’un objet S d’un sous type T doit pouvoir remplacer un objet de type T sans avoir de conséquences dans le comportement du programme. L’exemple concret le plus souvent utilisé pour évoquer ce principe est le rectangle ainsi que le carré. En effet, prenons le rectangle comme Type principal et le Carré comme sous type du rectangle (le Type carré est un rectangle particulier et donc potentiellement héritable du Type rectangle), la question est alors, le carré peut-il remplacer le rectangle dans le programme sans avoir de conséquences ? Eh bien non ! Si vous remplacez l’objet de type rectangle et que vous mettez un objet de type carré, avec quel coté du rectangle peut-on calculer l’air de cet objet vu que le carré ne possède qu’un seul coté, qu’une seule propriété, et que le type rectangle en possède deux ? Pour respecter ce principe, la technique consistera à créer une classe dont héritera le carré et le rectangle et par exemple de créer une méthode abstraite que chacune des figures implémentera afin de pouvoir calculer l’air. Ce principe est très peu utilisé honnêtement.

-Le I correspond à « Interface segregation » qui se traduit par ségrégation des interfaces. C’est une technique qui consiste à préférer la création de plusieurs petites interfaces qui concentre vraiment le domaine dans lequel elle a été produite plutôt qu’une seule qui contiendrait beaucoup trop de déclarations. Cela facilite beaucoup de choses comme les tests unitaires, une meilleure décomposition du code et donc une meilleure compréhension générale.

-Le D correspond à « Dependency Inversion » qui se traduit par inversion des dépendances. Ce principe permet d’inverser les dépendances entre les modules de vos applications. Concrètement, si vous avec un projet avec du code métier (Business Layer – BL) et un projet qui s’occupe de la persistance de vos données (Data Access Layer – DAL ), généralement votre projet BL référence votre projet DAL. Et bien avec ce principe, c’est justement l’inverse qui va se produire, vous n’allez plus faire référence à DAL dans votre projet BL et vous allez créer une abstraction et c’est à partir de là qu’intervient ce que l’on appelle une injection de dépendance. Ceci à des avantages à plus d’un titre : Faciliter les tests unitaires, gérer vos objets d’une manière responsable, remplacer votre DAL par une autre (changement d’une base de données), etc.