Principes STUPID
Maintenant que vous connaissez les principes SOLID, vous pouvez coder comme un pro et ne produire que du code de qualité. C'est parfait !
Eh bien, pas tout à fait. Vous restez un être humain. Et comme nous le savons tous, l'erreur est humaine et passe parfois inaperçue. Nous écrivons tous des codes qui parfois laissent à désirer, moi y compris. L'important, c'est d'en avoir conscience.
Mais alors, comment se rendre compte que nous sommes sur une mauvaise pente ?
Eh bien, il faut prendre le temps de relire son code.
Certes, votre code fonctionne. Mais pourrait-il être amélioré ? Prenez du recul, relisez-vous et vérifiez si vous avez malencontreusement suivi un des principes STUPID.
En résumé, les principes STUPID résultent de la non-application des principes SOLID. Plus précisément, l'acronyme STUPID signifie :
Singleton (Utilisation de singletons)
Tight coupling (Couplage fort)
Untestability (Impossible à tester)
Premature optimization (Optimisation prématurée)
Indescriptive naming (Nommage non descriptif)
Duplication
Passons-les en revue et étudions les problèmes associés à chacun de ces principes.
Utilisation de singletons
En C#, les singletons sont associés à l'utilisation du mot-clé static dans vos classes, méthodes et propriétés.
Il s'agit d'un design pattern très connu. Nous l'étudierons plus en détail dans la partie 3.
S'il s'agit d'un design pattern, pourquoi fait-il partie des principes STUPID ?
Les singletons sont très simples à utiliser et par conséquent ils sont souvent trop utilisés. Vous remarquerez rapidement qu'ils sont omniprésents dans votre code. Or, ce n'est pas une bonne pratique, notamment car on les considère comme des anti-patterns.
Qu'est-ce qu'un anti-pattern ?
Un anti-pattern est un processus ou pattern qui semble être une bonne idée, mais dont l'utilisation a en réalité plus de conséquences négatives que positives. D'autre part, il existe généralement une autre solution plus efficace.
Vous pouvez sans problème utiliser des singletons de temps à autre, mais ils sont souvent le symptôme d'un problème. Tout d'abord, les singletons introduisent un état global et sont difficiles à tester. De plus, les programmes qui s'appuient sur un état global cachent leurs dépendances.
Est-ce que je dois toujours les éviter ?
La réponse n'est pas tranchée. Chaque développeur a son idée sur la question.
Essayez d'éviter les éléments static susceptibles d'aboutir à un couplage fort.
Couplage fort
Nous avons déjà parlé du couplage fort lorsque nous avons évoqué le principe d'inversion des dépendances :
L'objectif est d'éviter la création d'un système fortement couplé dans lequel chaque module fait directement référence à des modules de niveau inférieur. C'est pour cette raison que vous devez opter pour l'abstraction afin d'obtenir un système moins couplé.
Une fois de plus, si vous modifiez un module dans votre application et que vous devez pour cela modifier un autre module, cela veut dire qu'ils sont couplés, ce qui les rend difficile à utiliser et à tester.
Impossible à tester
Vous avez peut-être remarqué que j'ai mentionné la difficulté de tester les singletons et les modules couplés. C'est un sérieux problème, car votre code doit pouvoir être testé.
Le moyen le plus efficace pour le faire est d'écrire des tests unitaires et d'intégration.
Optimisation prématurée
En bref, l'optimisation prématurée consiste à passer beaucoup de temps sur un point qui n'en vaut vraiment pas la peine. Donald Knuth y fait référence dans son ouvrage The Art of Computer Programming :
Le véritable problème est que les programmeurs consacrent bien trop de temps à l'efficacité de sections de code qui ne le méritent pas, et à des moments qui ne conviennent pas. L'optimisation prématurée est à l'origine de (presque) tous les problèmes en programmation.
Par exemple, imaginez qu'une entreprise passe trop de temps à réfléchir à la manière dont son application pourrait prendre en charge plusieurs millions d'utilisateurs. Il s'agit certes d'une préoccupation légitime, mais pas forcément celle qui devrait justifier votre action. Avant de réfléchir à la façon de gérer des millions d'utilisateurs, l'entreprise devrait surtout se préoccuper de savoir si les gens utiliseront l'application.
L'avis des clients devrait être la priorité !
Nommage non descriptif
Veillez à ce que votre code soit compréhensible ! N'utilisez pas des abréviations ou des conventions de nommage que vous êtes le seul à comprendre. Donnez des noms parlants à vos classes, variables, attributs et méthodes. D'autres développeurs liront votre code. Assurez-vous qu'il soit lisible et compréhensible.
Comme le dit Uncle Bob dans sa série de conférences vidéo (en anglais), "votre code doit se lire comme un bon livre".
Duplication
Si vous vous surprenez à faire du Ctrl+C/Ctrl+V dans votre application, arrêtez tout ! Vous êtes en train de dupliquer des sections du code.
Suivez ces deux principes de base :
Ne vous répétez pas (DRY - "Don't Repeat Yourself") : chaque information ou logique doit être représentée de manière unique et sans ambiguïté dans un système.
Faites simple (KISS - "Keep It Simple, Stupid!") : dans la plupart des cas, simplicité rime avec performance. La simplicité est l'objectif de votre conception.
En résumé
Les principes STUPID produisent des "code smells" (mauvais codes) :
Les singletons constituent un anti-pattern. Si leur utilisation semble être une bonne idée de prime abord, ils ont en réalité plus de conséquences négatives que positives. Par ailleurs, il existe une autre solution, plus efficace.
Un couplage fort consiste à rendre des modules dépendants d'autres modules.
L'impossibilité de tester correspond à des modules qu'il est impossible de tester en raison d'un couplage fort évident.
L'optimisation prématurée renvoie au fait de passer trop de temps sur ce dont vous pensez avoir besoin au détriment de ce dont vous avez réellement besoin.
Le nommage non descriptif consiste à ne pas donner des noms parlants à vos classes, variables, attributs et méthodes. Ne soyez pas énigmatique ! Faites en sorte que votre code se lise comme un bon livre.
La duplication consiste à répéter du code au sein de votre système. Respectez les principes DRY (ne pas se répéter) et KISS (faire simple).
Autrement dit, si vous ne suivez pas les principes SOLID, c'est que vous suivez les principes STUPID.
Maintenant que vous maîtrisez les grands principes, répondez à un petit quiz pour évaluer vos connaissances. Rendez-vous dans la partie 3. Nous y parlerons d'un nouvel outil pour écrire du code de qualité, les design patterns.
