Développement Web: Les 10 antipatternes de codage que vous devez é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 obligent 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, car les solutions au niveau architectural peuvent être réutilisées de la même manière que les fragments de code au niveau micro .

Les modèles de conception sont généralement des solutions réutilisables pour certains scénarios, qui peuvent s'avérer utiles pour résoudre des problèmes courants, et peuvent grandement nous aider à optimiser notre code.

Alors que les modèles de conception sont d'excellents moyens d'améliorer notre processus de développement en utilisant des formules éprouvées, nous pouvons parfois nous tromper avec eux. Ce sont les antipatternes.

Quels sont les antipatterns?

Le terme «antipattern» a été inventé dans un livre intitulé AntiPatterns en 1998. Il fait référence à des solutions réutilisées qui, au départ, semblent utiles, mais s'avèrent plus tard faire plus de mal que de bien.

Cela peut se produire 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 (les solutions qui étaient efficaces dans le passé ne fonctionnent pas toujours dans le présent) ou dans d'autres cas était juste mauvais depuis le début.

Les antipatternes sont aussi fréquemment appelés modèles d'échec . Les bonnes nouvelles sont qu'il est possible de les reconnaître et de les éviter .

Dans ce post, nous allons jeter un oeil à 10 anti-modèles de codage communs dans le développement web qui peuvent nous faire croire que nous avons un code bien optimisé. (Notez que les antipatternes listés dans ce post ne sont pas nécessairement les mêmes que ceux 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. Nous pouvons facilement reproduire l'anti-modèle de «l'optimisation prématurée», si nous prêtons attention aux petites efficacités et les optimisons trop tôt dans le processus de développement, avant de savoir exactement ce que nous voulons faire.

Selon la citation célèbre de Donald Knuth "l'optimisation prématurée est la racine de tout le mal", ce qui peut être une exagération, mais montre encore à quel point des problèmes graves peuvent causer une optimisation prématurée.

Si nous optimisons les performances avant de configurer une architecture efficace, nous pouvons réduire la lisibilité du code, rendre plus difficile le débogage et la maintenance, et ajouter des parties superflues à notre code.

Pour éviter une optimisation prématurée, il est recommandé de suivre le principe de programmation de YAGNI, qui conseille de «toujours implémenter les choses quand vous en avez vraiment besoin, jamais quand vous prévoyez juste que vous en avez besoin».

2. Réinventer la roue

L'anti-modèle «réinventer la roue» est parfois appelé «concevoir dans le vide» . Cela arrive quand nous voulons tout faire par nous - mêmes et tout écrire à partir de zéro, sans chercher des méthodes, des API ou des bibliothèques déjà existantes.

Réinventer la roue n'est pas seulement une chose fastidieuse à faire, mais les solutions personnalisées, en particulier pour les fonctionnalités de base, sont rarement aussi bonnes que celles standard qui ont déjà été testées par de nombreux développeurs et utilisateurs.

3. L'enfer de dépendance

Le contraire de l'antipattern "réinventer la roue" est un autre antipattern commun appelé "enfer de dépendance" .

Si, au lieu de tout écrire à partir de zéro, nous utilisons trop de bibliothèques tierces qui dépendent de versions spécifiques d'autres bibliothèques, nous pouvons facilement nous retrouver dans une situation difficilement gérable lorsque nous voulons mettre à jour, car ces dépendances subsidiaires sont souvent incompatibles avec l'un l'autre .

L'enfer des dépendances peut être résolu 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, le refactoring peut aussi être une bonne idée.

4. Code Spaghetti

Le "code spaghetti" est probablement l'anti-modèle codant le plus connu. Il décrit une application difficile à déboguer ou à modifier en raison de l'absence d'une architecture appropriée .

Le résultat d'une conception de logiciel médiocre est un tas de code qui est similaire dans sa structure à un bol de spaghetti, c'est-à-dire emmêlé et alambiqué . La lisibilité du code spaghetti est très faible, et c'est habituellement une mission presque impossible de comprendre comment cela fonctionne exactement.

Le code spaghetti provient généralement de la combinaison de différentes mauvaises pratiques de codage, telles que le code ne contenant pas de blocs conditionnels corrects, ayant beaucoup d'instructions goto, d'exceptions et de threads, contenant des parties qui appartiennent ailleurs, des relations minimales entre objets, méthodes qui ne peuvent être réutilisées ou qui ne sont pas documentées correctement ou pas du tout.

5. Programmation par permutation

«Programmation par permutation» ou «programmation par accident» se produit lorsque nous essayons de trouver une solution à un problème en expérimentant successivement de petites modifications, en les testant et en les évaluant un par un, puis en mettant en œuvre celui qui fonctionne.

La programmation par permutation peut facilement introduire de nouveaux bugs dans notre code, pire encore, ce sont des bugs que nous ne reconnaissons pas forcément en même temps. Dans de nombreux cas, il est également impossible d'anticiper si la solution fonctionnera pour tous les scénarios possibles ou non.

6. Copiez et collez la programmation

"Copier et coller la programmation" se produit lorsque nous ne respectons pas le principe de codage "Ne vous répétez pas" (DRY). Au lieu de créer des solutions génériques, nous insérons des extraits de code déjà existants à différents endroits et les modifions par la suite. contexte donné.

Cette pratique résulte en un code qui est hautement répétitif, car les parties de code insérées ne diffèrent généralement que par des différences mineures.

La programmation par copier-coller est non seulement réalisée par des développeurs novices, mais aussi par des programmeurs expérimentés, car beaucoup d'entre eux sont enclins à utiliser leurs propres extraits de code pré-écrits et testés pour des tâches spécifiques, ce qui peut facilement conduire à des répétitions involontaires .

7. Programmation Cargo-Cult

Le nom de "programmation culte-cargo" provient d'un phénomène ethnographique spécifique appelé "cargo cargo". Les cultes de cargaison sont apparus dans le Pacifique Sud après la seconde guerre mondiale, quand le contact forcé avec les civilisations avancées a conduit les indigènes à penser que les produits manufacturés, tels que Coca-Cola, téléviseurs et réfrigérateurs apportés par les cargos aux îles, ont été créés par surnaturel. méthodes et s'ils accomplissent des rites magiques semblables aux coutumes des Occidentaux, la cargaison remplie de marchandises reviendra.

Quand nous commettons l'antipattern de la programmation du 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 les autres, sans comprendre pourquoi nous le faisons, ou comment ces technologies fonctionnent exactement.

Dans de nombreux cas, les développeurs font rituellement ce qui est de la hanche à ce moment-là sans aucun but réel . Cette pratique est non seulement mauvaise car elle rend notre application superflue, mais elle peut aussi facilement introduire de nouveaux bogues dans notre code.

8. Flux de lave

Nous parlons de l'antipattern "flow lave" quand nous avons besoin de traiter un code qui a des parties redondantes ou de basse qualité qui semblent faire partie intégrante du programme, mais nous ne comprenons pas complètement ce qu'il fait ou comment cela affecte l'ensemble de l'application . Cela rend risqué de l'enlever.

Cela arrive généralement avec du code existant, ou lorsque le code a été écrit par quelqu'un d'autre (généralement sans la documentation appropriée), ou lorsque le projet est passé trop vite de la phase de développement à la phase de production.

Le nom de l'antipattern vient de sa ressemblance avec la lave provenant des volcans, c'est-à-dire qu'il se déplace d'abord rapidement et de façon fluide sans prendre trop de précautions, mais plus tard il se solidifie et devient difficile à enlever.

En théorie, nous pouvons nous débarrasser des coulées de lave avec des tests approfondis et des refactoring, mais dans la pratique, la mise en œuvre est souvent difficile, voire impossible . Comme les coulées de lave ont généralement des coûts de performance élevés, il est préférable de les prévenir en mettant en place une architecture bien conçue et un workflow sain dès le départ.

9. Codage dur

"Hard coding" est un anti-modèle bien connu contre lequel la plupart des livres de développement web nous avertissent directement dans la préface. Le codage hard est la pratique malencontreuse dans laquelle nous stockons des données de configuration ou d'entrée, comme un chemin de fichier ou un nom d'hôte distant, dans le code source plutôt que de l'obtenir depuis un fichier de configuration, une base de données, une entrée utilisateur ou une autre source externe. .

Le principal problème avec le code dur est qu'il 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 différents.

10. Codage souple

Si nous essayons très fort d'éviter le piège du codage dur, nous pouvons facilement rencontrer un autre antipattern appelé "soft coding", qui est exactement son contraire.

Dans le codage logiciel, nous mettons des éléments 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é peut devenir si abstrait et compliqué qu'il est presque impossible de le comprendre (en particulier pour les nouveaux membres de l'équipe), et extrêmement difficile à maintenir et à déboguer .