Du chaos à la clarté : le rôle essentiel de l'architecture

Dans le monde trépidant du développement moderne, l'architecture détermine souvent si un projet prospère ou s'effondre sous sa propre complexité. Même si de nombreux développeurs comprennent intuitivement l’importance de l’architecture, le « pourquoi » et le « comment » sont moins fréquemment abordés. Qu'est-ce qui rend l'architecture si critique et comment pouvez-vous garantir que vos choix mènent à la clarté plutôt qu'au chaos ?

Cet article est utile aux développeurs React, Vue, Svelte et Vanilla JS. Cela peut être moins utile pour les développeurs Angular, car Angular applique des modèles d'architecture stricts par défaut, même si cela peut toujours apporter de la valeur.

À mon avis, il y a un manque d'informations détaillées sur l'architecture sur Internet ; J'ai réussi à trouver seulement quelques ressources utiles. C'est pourquoi j'ai décidé de créer une série d'articles sur l'architecture.

Pour l'instant, explorons ce qu'est l'architecture, pourquoi nous avons besoin d'architecture, introduisons quelques termes clés et discutons de différents types d'architectures

Le problème

Imaginez démarrer un nouveau projet sans planifier son architecture, en plongeant simplement dans le code. Vous développez votre premier module, qui contient des liens entre les sous-modules et les composants. Ensuite, vous créez un deuxième module et le liez au premier. Ce modèle se poursuit à mesure que vous ajoutez davantage de modules et de connexions.

Le problème survient lorsque vous devez supprimer ou modifier un module. À mesure que votre projet grandit, sa complexité augmente également, avec d'innombrables modules, sous-modules et connexions floues entre eux. Finalement, cette toile enchevêtrée devient un casse-tête pour les développeurs et une maintenance plus coûteuse pour l'entreprise.

Difficulté === Temps === Argent

Qu’est-ce que l’Architecture ?

De nombreux développeurs pensent à tort que l’architecture est équivalente à une structure de dossiers, mais c’est incorrect. L'architecture va au-delà de l'organisation des fichiers. Il décrit comment les modules et les composants interagissent au sein du système de projet.

L'architecture englobe divers éléments d'un projet, spécifiant comment les modules et les composants doivent être développés et comment ils doivent s'interconnecter.

Dans le frontend, les modules sont généralement des composants d'interface utilisateur qui utilisent la logique métier. Ceux-ci peuvent aller de gros composants, comme des pages, à de petits composants, comme des entrées, des boutons ou une typographie.

Que devrait avoir une bonne conception logicielle ?

Nous devons nous assurer que les modules de notre projet ont :

1. Haute cohésion – Chaque module doit contenir une logique métier associée.
2. Faible couplage – Les modules doivent être aussi indépendants les uns des autres que possible.

La

Cohésion fait référence à ce que le module peut faire. Une faible cohésion signifierait que la classe effectue une grande variété d’actions – elles sont larges et peu ciblées sur ce qu’elle devrait faire. Une cohésion élevée signifie que la classe se concentre sur ce qu'elle doit faire, c'est-à-dire uniquement sur les méthodes liées à l'intention de la classe.

Le

Couplage fait référence à la façon dont deux modules sont liés ou dépendants l'un par rapport à l'autre. Pour les modules faiblement couplés, changer quelque chose d'important dans une classe ne devrait pas affecter l'autre. Un couplage élevé rendrait difficile la modification et la maintenance de votre code. Étant donné que les modules sont étroitement liés, apporter un changement pourrait nécessiter une refonte complète du système.

Essentiellement, une cohésion élevée signifie conserver les morceaux de code associés ensemble au même endroit. Dans le même temps, un faible couplage implique de séparer autant que possible les parties non liées de la base de code.

Voici l'explication de l'image :

Les modules de l'image sont représentés par des groupes de cercles distincts, faciles à repérer. Chaque cercle d'un module représente une classe ou un composant responsable de l'exécution d'une tâche spécifique. Les cercles de la même couleur au sein d'un module indiquent les éléments qui résolvent la même tâche. Les flèches dans l'image représentent les connexions entre les modules, illustrant comment ils interagissent les uns avec les autres.

Cohésion élevée, couplage élevé

Considérons l'anti-modèle Dieu objet. Un objet Dieu est un module qui comporte plusieurs sous-modules et interconnexions, tout en tentant également de résoudre plusieurs tâches simultanément.

Cela se traduit par une cohésion élevée car un seul module est responsable de plusieurs tâches, et un couplage élevé en raison des connexions floues entre les différents modules et sous-modules.

Faible cohésion, faible couplage

Dans ce scénario, les modules sont bien divisés, mais les sous-modules à l'intérieur résolvent différentes tâches (indiquées par les différentes couleurs dans l'image). Cependant, les connexions entre les modules ne sont toujours pas claires.

Faible cohésion, couplage élevé

C'est un cas différent. Ici, les modules sont clairement divisés et les connexions entre eux sont solides. Cependant, à l'intérieur de chaque module, la cohésion est faible car ils résolvent plusieurs tâches, conduisant à une complexité inutile.

Néanmoins, c'est toujours mieux que les deux exemples précédents car vous pouvez supprimer ou modifier des modules individuels sans trop de difficulté.

Cohésion élevée, faible couplage – L’idéal

Dans une architecture idéale, les liens entre les modules sont « faibles », ce qui facilite la suppression ou la modification de n'importe quel module. Au sein de chaque module, les composants et les classes résolvent une tâche spécifique (comme l'indique leur couleur uniforme), et il n'y a pas de mélange de responsabilités, contrairement aux exemples précédents.

Bien que cette architecture idéale soit rare dans les projets, car elle nécessite des connaissances et une expérience spécifiques, c'est quelque chose que nous devrions tous rechercher.

Conclusion

L'architecture est la structure des modules, des composants et les connexions entre eux.

La clé d'une architecture réussie réside dans la mise en œuvre de principes de développement tels que DRY, KISS et SOLID. Supprimer et modifier des modules doit être facile, en particulier la partie suppression, c'est un point majeur.

Faites-moi savoir dans les commentaires si vous avez des questions ou sur quelle architecture vous aimeriez en savoir plus !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!