Développement Web Les 10 antipatternes de codage à éviter
La conception de l'architecture d'un site Web ou d'une application, ou la mise en place d'un flux de travail de codage efficace nous oblige souvent à faire face à des problèmes récurrents. Nous n'avons pas nécessairement besoin de résoudre ces problèmes de conception de logiciels à partir de zéro, les solutions au niveau architectural peuvent être réutilisées de la même façon que extraits de code au niveau micro.
Les modèles de conception sont généralement solutions réutilisables pour certains scénarios, cela peut être pratique pour résoudre les problèmes courants, et peut nous aider énormément à optimiser notre code.
Bien que les modèles de conception constituent un excellent moyen d’améliorer notre processus de développement en utilisant des formules bien testées, nous pouvons parfois nous tromper. Celles-ci s'appellent des antipatterns.
Quels sont les antipatternes?
Le terme “anti-modèle” a été inventé dans un livre intitulé AntiPatterns en 1998. Il fait référence à solutions réutilisées qui semblent initialement utiles, mais plus tard s'avère faire plus de mal que de bien.
Cela peut arriver pour différentes raisons, par exemple si nous n'utilisons pas les modèles dans le bon contexte, le bon contexte ou le bon moment (des solutions qui étaient efficaces dans le passé peuvent ne pas toujours fonctionner dans le présent), ou dans d'autres cas, le paradigme entier était juste mauvais dès le début.
Les antipatternes sont aussi souvent appelés modèles d'échec. La bonne nouvelle est que c'est possible de les reconnaître et de les éviter.
Dans cet article, nous examinerons 10 antipatterns de codage courants dans le développement Web qui pourraient nous induire en erreur en pensant que nous avons un code bien optimisé. (Notez que les antipatterns listés dans ce post ne sont pas nécessairement les mêmes que ce que vous pouvez trouver dans le livre mentionné ci-dessus.)
1. Optimisation prématurée
Un bon timing est un facteur crucial dans l'optimisation du code. On peut facilement reproduire l'antipattern de “optimisation prématurée”, si nous accordons une attention particulière aux petites économies et les optimisons trop tôt dans le processus de développement, avant de savoir exactement ce que nous voulons faire.
Selon la célèbre citation de Donald Knuth “L'optimisation prématurée est la racine de tout Mal“, peut être une exagération, mais montre tout de même à quel point des problèmes graves d’optimisation précoce peuvent provoquer.
Si nous optimisons les performances avant de mettre en place une architecture efficace, nous pouvons lisibilité moindre du code, faire le débogage et la maintenance plus difficile, et ajouter des pièces superflues à notre code.
Pour éviter une optimisation prématurée, il est judicieux de suivre le principe de programmation YAGNI (Vous n’allez pas en avoir besoin), qui recommande de: “mettez toujours les choses en place quand vous en avez réellement besoin, jamais quand vous prévoyez en avoir besoin.”
2. Réinventer la roue
le “Réinventer la roue” antipattern est parfois aussi appelé “concevoir en vase clos”. Ça arrive quand on veut tout faire par nous-mêmes et tout écrire à partir de zéro, sans rechercher de méthodes, API ou bibliothèques déjà existantes.
Réinventer la roue n’est pas seulement une perte de temps, mais bien les solutions personnalisées, en particulier pour les fonctionnalités de base, sont rarement aussi bonnes que les solutions standard qui ont déjà été testés par de nombreux développeurs et utilisateurs.
3. L'enfer de la dépendance
Le contraire de la “Réinventer la roue” antipattern est un autre antipattern commun appelé “dépendance enfer”.
Si, au lieu d’écrire tout à partir de zéro, nous utilisons trop de bibliothèques tierces qui s'appuient sur des versions spécifiques d'autres bibliothèques, nous pouvons facilement nous retrouver dans une situation difficilement gérable lorsque nous souhaitons mettre à jour, car ces dépendances subsidiaires le sont souvent incompatibles les uns avec les autres.
La dépendance de l’enfer peut être résolue en utilisant des gestionnaires de paquets capables de mettre à jour intelligemment les dépendances interdépendantes. Si nous sommes trop submergés par le problème, la refactorisation peut aussi être une bonne idée.
4. Code de spaghetti
“Code spaghetti” est probablement l'antipattern de codage le plus célèbre. Il decrit une application difficile à déboguer ou à modifier en raison de l'absence d'architecture appropriée.
Le résultat d’une mauvaise conception logicielle est un tas de code dont la structure est semblable à celle d’un bol de spaghettis, c’est-à-dire. emmêlé et alambiqué. La lisibilité du code spaghetti est très faible et il est généralement difficile de comprendre comment cela fonctionne..
Le code spaghetti provient généralement du combinaison de différentes mauvaises pratiques de codage, tel que le code ne contenant pas les blocs conditionnels appropriés, ayant beaucoup d'instructions goto, d'exceptions et de threads, contenant des parties qui appartiennent ailleurs, a des relations minimales entre les objets, a des fonctions ou des méthodes qui ne peuvent pas être réutilisées, ou qui ne sont pas documentées correctement du tout.
5. Programmation par permutation
“Programmation par permutation” ou “programmation par accident” arrive quand nous essayons de trouver une solution à un problème en expérimentant successivement de petites modifications, en les testant et en les évaluant une par une, puis en mettant en œuvre celle qui fonctionne au premier abord.
La programmation par permutation peut facilement introduire de nouveaux bogues dans notre code, pire encore, ce sont des insectes que nous ne reconnaissons pas nécessairement à la fois. Dans de nombreux cas, il est également impossible de prévoir si la solution fonctionnera ou non pour tous les scénarios possibles..
6. Copier et coller la programmation
“Copier et coller la programmation” se produit lorsque nous ne suivons pas le principe de codage Ne répétez pas vous-même (DRY) et qu'au lieu de créer des solutions génériques, nous insérons des extraits de code déjà existants à différents endroits, puis les modifions pour les adapter au contexte donné.
Cette pratique résulte en un code qui est très répétitif, comme les parties de code insérées ne diffèrent généralement que par des divergences mineures.
La programmation par copier / coller n’est pas seulement engagée par les développeurs novices, mais aussi par les programmeurs expérimentés, car beaucoup d’entre eux sont enclins à utiliser leurs propres extraits de code pré-écrits et bien testés pour des tâches spécifiques, qui peut facilement conduire à répétitions involontaires.
7. Programmation cargo-culte
Le nom de “programmation culte du cargo” provient d'un phénomène ethnographique spécifique appelé “culte de la cargaison”. Les cultes du fret sont apparus dans le Pacifique Sud après la seconde guerre mondiale, lorsque le contact forcé avec des civilisations avancées a conduit les autochtones à penser que des produits manufacturés, tels que Coca-Cola, des téléviseurs et des réfrigérateurs apportés par des cargos dans les îles, avaient été créés par des surnaturels. les méthodes; et s'ils accomplissent des rites magiques semblables aux coutumes des Occidentaux, la cargaison remplie de marchandises reviendra.
Lorsque nous commettons l'antagoniste d'une programmation culte de la cargaison, nous faisons essentiellement la même chose. Nous utilisons des cadres, des bibliothèques, des solutions, des modèles de conception, etc. qui ont bien fonctionné pour d'autres, sans comprendre pourquoi nous le faisons, ou comment ces technologies fonctionnent exactement.
Dans de nombreux cas, les développeurs ont juste rituellement faire ce qui est hip à cette époque sans but réel. Cette pratique est non seulement mauvaise car elle rend notre application excessivement gonflée, mais elle peut également introduire facilement de nouveaux bogues dans notre code..
8. écoulement de lave
On parle de la “coulée de lave” anti-modèle quand nous devons traiter avec du code contenant des pièces redondantes ou de mauvaise qualité cette semble faire partie intégrante au programme, mais nous ne comprenons pas complètement ce qu’il fait ou comment il affecte toute l’application. Cela rend risqué de l'enlever.
Cela arrive généralement avec code hérité, ou quand le le code a été écrit par quelqu'un d'autre (généralement sans documentation appropriée), ou lorsque le projet est passé trop rapidement de la phase de développement à la phase de production.
Le nom de l'antipattern vient de sa ressemblance avec la lave provenant de volcans, c'est-à-dire qu'il se déplace d'abord rapidement et avec fluidité sans prendre trop de précautions, puis qu'il se solidifie et devient difficile à enlever..
En théorie, nous pouvons nous débarrasser des coulées de lave avec essais approfondis et refactoring, mais en pratique, la mise en œuvre est souvent difficile voire impossible. Les coulées de lave ayant généralement des coûts de performance élevés, il est préférable de les éviter en mettant en place une architecture bien conçue et un flux de travail sonore dès le départ..
9. Codage dur
“Codage dur” est un antipattern bien connu contre lequel la plupart des livres de développement Web nous préviennent dès la préface. Le codage en dur est la pratique malheureuse dans laquelle nous stockons la configuration ou les données d'entrée, tel qu'un chemin de fichier ou un nom d'hôte distant, dans le code source plutôt que de l'obtenir à partir d'un fichier de configuration, d'une base de données, d'une entrée utilisateur ou d'une autre source externe.
Le principal problème avec le code dur est que cela ne fonctionne correctement que dans un certain environnement, et à chaque fois que les conditions changent, nous devons modifier le code source, généralement à plusieurs endroits distincts.
10. Codage souple
Si nous essayons très dur d’éviter le piège du codage difficile, nous pouvons facilement nous heurter à un autre anti-modèle appelé “codage souple”, quel est son opposé.
En codage souple, nous mettons des choses qui devraient être dans le code source dans des sources externes, Par exemple, nous stockons la logique métier dans la base de données. La raison la plus courante pour laquelle nous le faisons est la crainte que les règles métier ne changent à l'avenir. Nous devrons donc réécrire le code..
Dans les cas extrêmes, un programme codé en douceur peut devenir si abstrait et alambiqué qu'il est presque impossible de le comprendre (surtout pour les nouveaux membres de l’équipe), et extrêmement difficile à maintenir et à déboguer.
