Loi de Conway et séparation des préoccupations dans le développement Web

La loi de Conway, qui stipule que les systèmes logiciels ont tendance à refléter les structures de communication des organisations qui les construisent, joue un rôle crucial dans la façon dont le développement Web moderne est structuré. L’évolution des premières pratiques vers les systèmes plus complexes d’aujourd’hui, comme les micro-frontends et les architectures basées sur des composants, a été largement façonnée par ce principe. En examinant comment les préoccupations ont été historiquement séparées dans le développement Web, nous pouvons mieux comprendre comment les pratiques actuelles ont émergé et pourquoi elles ressemblent à ce qu'elles sont aujourd'hui.

Au début du développement Web, différentes équipes étaient souvent responsables de technologies spécifiques. Une équipe s'occupait du HTML, une autre s'occupait du CSS et une autre encore s'occupait du JavaScript et de la logique côté serveur, comme PHP. Cette séparation claire des responsabilités, ou « séparation des préoccupations », était motivée par les compétences distinctes que possédait chaque équipe. Les concepteurs remettraient des fichiers Photoshop au pixel près à une équipe, qui les transformerait ensuite en modèles HTML et CSS. Une fois les modèles créés, l'équipe suivante les intégrait dans l'application, rencontrant souvent des frictions lorsque les choses ne s'adaptaient pas parfaitement.

Un concepteur pourrait fournir un fichier .psd avec les neuf coins d'un tableau méticuleusement conçus, et l'équipe HTML/CSS le découperait en une mise en page fonctionnelle. Mais ils étaient largement déconnectés de la logique réelle de l’application ou des interactions des utilisateurs. Leur travail consistait simplement à s’assurer que les visuels fonctionnaient. L’équipe backend, chargée de PHP et JavaScript, intégrait ensuite ces modèles statiques dans l’application fonctionnelle, trouvant souvent que les solutions présentées par les équipes précédentes n’étaient pas idéales pour les besoins de l’application. Cela reflétait la façon dont les organisations étaient structurées, chaque équipe étant propriétaire d'une partie différente du processus sans beaucoup de communication croisée.

Le passage à une architecture basée sur les composants

Aujourd’hui, la façon dont nous séparons les préoccupations a radicalement changé. Au lieu de répartir les responsabilités par technologie (par exemple, une équipe pour HTML et CSS et une autre pour JavaScript et PHP), les équipes modernes sont plus susceptibles d'être responsables de l'ensemble de la pile de parties spécifiques de l'application. Chaque équipe possède généralement une tranche verticale de l'application, comprenant tout, des composants frontend à la logique backend. Ce changement est motivé par la montée en puissance des architectures basées sur des composants, dans lesquelles les composants réutilisables et autonomes sont les éléments constitutifs du système.

Par exemple, au lieu d'une équipe se concentrant sur tout le HTML et le CSS sur l'ensemble du site, et d'une autre équipe gérant le JavaScript et l'intégration côté serveur, vous avez désormais des équipes responsables de fonctionnalités ou de composants distincts, tels que < ;Article>, ou . Chaque équipe gère son composant ou partie de l'application de haut en bas, y compris la logique frontend et backend. Cela permet aux équipes de travailler de manière plus autonome, réduisant ainsi les goulots d'étranglement et les problèmes de communication qui survenaient souvent dans l'ancien modèle de séparation.

Cette nouvelle séparation des préoccupations, par fonctionnalité ou composant plutôt que par technologie, permet aux équipes d'itérer plus rapidement. Une équipe responsable d'un widget de chat, par exemple, peut implémenter des modifications à la fois dans l'interface utilisateur et dans l'API backend sans attendre qu'une autre équipe gère une partie du système. La principale différence est désormais qu'au lieu d'avoir des équipes spécialisées axées uniquement sur HTML ou JavaScript, vous disposez d'équipes interfonctionnelles qui s'approprient leurs composants ou fonctionnalités dans leur intégralité.

Micro-frontends et propriété d’équipe indépendante

L'un des résultats les plus significatifs de ce changement est la montée en puissance des micro-frontends, où différentes équipes possèdent différentes parties du frontend, tout comme elles possèdent des parties du backend. Cela permet un niveau d’indépendance qui n’était pas possible au début. Une architecture micro-frontend reflète l'indépendance dont disposent désormais les équipes dans la gestion de leurs composants.

Par exemple, une équipe responsable de peut tout posséder, de la structure de l'interface utilisateur à la manière dont elle interagit avec les données extraites des API. Une autre équipe responsable de

aura un contrôle total sur la façon dont les articles sont récupérés, rendus et interagis avec, de la logique frontale aux requêtes de base de données. Ce niveau d'autonomie signifie que les changements peuvent être déployés de manière indépendante, sans avoir besoin de se coordonner avec d'autres équipes autant que par le passé.

En revanche, dans l'ancien modèle de séparation HTML CSS vs JS PHP, les modifications apportées à n'importe quelle partie du système nécessitaient une coordination entre plusieurs équipes. Si le frontend avait besoin d'une nouvelle fonctionnalité, l'équipe HTML/CSS devrait travailler avec l'équipe JavaScript pour garantir que la nouvelle mise en page ou la nouvelle fonctionnalité fonctionnait comme prévu. Aujourd'hui, avec des équipes possédant des composants ou des fonctionnalités spécifiques de haut en bas, ce besoin de coordination inter-équipes est considérablement réduit, permettant des cycles de développement et de déploiement plus rapides.

La loi de Conway en action

La loi de Conway reste toujours aussi pertinente. La façon dont nous construisons nos logiciels aujourd'hui reflète toujours la façon dont nos équipes sont organisées, mais la différence est que les structures d'équipe modernes sont davantage axées sur les fonctionnalités et moins cloisonnées sur la technologie. L'ancienne méthode de répartition des responsabilités par technologie (HTML CSS vs. JS PHP) a cédé la place à un modèle où chaque équipe est responsable d'une fonctionnalité ou d'un composant complet.

Cette séparation moderne des préoccupations permet une meilleure communication au sein des équipes et une appropriation plus ciblée. Les micro-frontends, les architectures basées sur des composants et les équipes axées sur les fonctionnalités sont tous le reflet de la vision de Conway : votre logiciel reflétera inévitablement la structure de votre équipe. À mesure que les structures de nos équipes évoluent, les systèmes que nous construisons évoluent également, devenant plus flexibles, modulaires et indépendants.

Conclusion

Le passage d'une séparation des préoccupations basée sur la technologie à une séparation basée sur les fonctionnalités a révolutionné la façon dont nous construisons des applications Web. La loi de Conway explique pourquoi cette évolution s'est produite : à mesure que les équipes sont devenues plus autonomes et axées sur les fonctionnalités, l'architecture de nos systèmes a emboîté le pas. Les micro-frontends, les bibliothèques de composants internes et le développement basé sur des composants reflètent tous le besoin moderne d'équipes indépendantes et interfonctionnelles qui possèdent à la fois le frontend et le backend de leurs fonctionnalités ou composants spécifiques.

Bien que les outils et les frameworks aient évolué, le principe fondamental reste le même : la façon dont les équipes sont structurées influence directement les logiciels qu'elles construisent. En comprenant la loi de Conway et l'histoire de la séparation des préoccupations, nous pouvons mieux apprécier les systèmes avec lesquels nous travaillons aujourd'hui et anticiper comment ils pourraient continuer à évoluer.

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!