Introduction aux anti-modèles
Les anti-modèles sont l'exact opposé des modèles. Rappelons que les patrons de conception sont des exemples de bonnes pratiques de programmation, c'est-à-dire des patrons pour résoudre certains problèmes. Mais les anti-modèles sont leur contraire, c'est-à-dire des modèles d'erreurs commises lors de la résolution de divers problèmes.
Une bonne pratique de programmation consiste précisément à éviter les anti-modèles. Ne pensez pas qu'il s'agit d'une telle poubelle théorique incompréhensible - ce sont des problèmes spécifiques que presque tous les développeurs ont rencontrés. Qui est au courant, il est armé !
Examinons quelques anti-modèles courants chez les débutants :
- Nombres et chaînes magiques
- classe de dieu
- Optimisation prématurée
- l'invention du vélo
- Invention du monocycle
Nombres et chaînes magiques
Un nombre magique est une constante utilisée dans le code pour quelque chose (le plus souvent l'identification des données), dont le nombre lui-même n'a aucun sens sans un commentaire correspondant. Les nombres ne portent absolument aucune sémantique.
Lorsque des chiffres commencent à apparaître dans le code de votre projet, dont la signification n'est pas évidente, c'est très mauvais. Un programmeur qui n'est pas l'auteur d'un tel code aura du mal à en expliquer le fonctionnement. Au fil du temps, même l'auteur du code avec des nombres magiques ne pourra pas l'expliquer.
Les nombres rendent le code difficile à comprendre et à refactoriser. Les principales raisons de cette erreur sont la hâte du développement et le manque de pratique de la programmation. Cet anti-modèle devrait être étouffé dans l'œuf en stipulant l'utilisation de constantes numériques avant de commencer le développement.
Pour résoudre ce problème, vous devez créer une variable dont le nom explique le but de la constante numérique et lui attribuer la valeur souhaitée.
classe de dieu
L'objet divin est un anti-modèle assez courant chez les développeurs de POO. Un tel objet prend trop de fonctions et/ou stocke la quasi-totalité des données. Du coup, on a un code non portable, qui, de surcroît, est difficile à comprendre.
De plus, un tel code est assez difficile à maintenir, étant donné que tout le système en dépend presque exclusivement. Raisons de cette erreur : incompétence du développeur, un développeur prenant en charge une grande partie du travail (en particulier lorsque la quantité de travail dépasse le niveau d'expérience de ce développeur).
Il est nécessaire de gérer cette approche en divisant les tâches en sous-tâches que différents développeurs peuvent gérer.
Optimisation prématurée
L'optimisation prématurée est une optimisation qui est effectuée avant que le programmeur ne dispose de toutes les informations nécessaires pour prendre des décisions éclairées sur où et comment le faire.
En pratique, il est difficile de prédire où se produira un goulot d'étranglement. Les tentatives d'optimisation avant d'obtenir des résultats empiriques conduiront à la complexité du code et à l'apparition d'erreurs, mais n'apporteront aucun bénéfice.
Comment éviter? Tout d'abord, écrivez un code propre, lisible et fonctionnel à l'aide d'algorithmes et d'outils bien connus et éprouvés. Si nécessaire, utilisez des outils de profilage pour trouver les goulots d'étranglement. Fiez-vous aux mesures, pas aux suppositions et aux suppositions.
Exemples et fonctionnalités
Mise en cache avant le profilage. Utiliser des heuristiques complexes et non éprouvées au lieu d'algorithmes mathématiquement corrects. Une sélection de nouveaux frameworks non testés qui peuvent mal se comporter sous charge.
Quelle est la difficulté
Il n'est pas facile de déterminer quand l'optimisation est prématurée. Il est important de laisser la place à la croissance à l'avance. Vous devez choisir des solutions et des plates-formes qui vous permettent d'optimiser et de croître facilement. De plus, une optimisation prématurée est parfois utilisée comme excuse pour un mauvais code. Par exemple, ils prennent un algorithme O(n2) uniquement parce que l'algorithme serait O(n) plus difficile.
l'invention du vélo
La signification de cet anti-pattern est que le programmeur développe sa propre solution à un problème pour lequel des solutions existent déjà, et souvent beaucoup plus réussies.
Le développeur se considère plus intelligent, il essaie donc de trouver sa propre solution pour chaque tâche, malgré l'expérience de ses prédécesseurs. Le plus souvent, cela n'entraîne qu'une perte de temps et une diminution de l'efficacité du programmeur. Après tout, la solution est susceptible d'être sous-optimale, si elle est trouvée.
Bien sûr, vous ne pouvez pas complètement écarter la possibilité d'une solution indépendante, car cela conduira à une programmation par copier-coller de manière directe. Le développeur doit naviguer dans les tâches qui peuvent apparaître devant lui afin de les résoudre avec compétence, en utilisant des solutions toutes faites ou en inventant les siennes.
Très souvent, la raison de cet anti-pattern est un simple manque de temps. Et le temps c'est de l'argent.
Invention du vélo à roue carrée
Cet anti-modèle est très étroitement lié à la simple réinvention de la roue - créer votre propre mauvaise solution lorsqu'une meilleure solution existe.
Cet anti-modèle prend deux fois plus de temps : d'abord, le temps est consacré à inventer et à mettre en œuvre votre propre solution, puis à la refactoriser ou à la remplacer.
Le programmeur doit être conscient de l'existence de diverses solutions pour certaines gammes de tâches, être guidé par leurs avantages et leurs inconvénients.
Tous les problèmes auxquels vous serez confronté en tant que programmeur peuvent être divisés en deux parties :
- des gens intelligents ont résolu ce problème il y a 30 ans
- des gens intelligents ont résolu ce problème il y a 50 ans
La plupart des problèmes de programmation ont été résolus avec succès avant même votre naissance . Inutile d'inventer quoi que ce soit - étudiez simplement l'expérience des autres (c'est pour cela que les livres sont écrits).
En 2022, nous pouvons fêter les anniversaires suivants :
- Langages de programmation
- Le langage C fête ses 50 ans (1972)
- Le langage Java a eu 27 ans (1995)
- Python fête ses 31 ans (1991)
- Connexion
- Internet a eu 39 ans (1983)
- Le téléphone portable a eu 49 ans (1973)
- Le premier SMS a été envoyé il y a 30 ans (1992)
- Motifs
- Le modèle MVC a eu 44 ans (1978)
- SQL a été inventé il y a 48 ans (1974)
- Les Java Beans ont été inventés il y a 26 ans (1996)
- Bibliothèques
- Hibernate a été inventé il y a 21 ans (2001)
- Le printemps a été inventé il y a 20 ans (2002)
- Tomcat sorti il y a 23 ans (1999)
- SE
- Unix est sorti il y a 51 ans (1971)
- Windows a vu le jour il y a 37 ans (1985)
- Mac OS sorti il y a 21 ans (2001)
Et toutes ces choses n'ont pas été simplement inventées, elles ont été développées comme des solutions à des problèmes qui étaient très courants et pertinents à l'époque.
GO TO FULL VERSION