Conways Gesetz und Trennung von Belangen in der Webentwicklung

Conways Gesetz, das besagt, dass Softwaresysteme dazu neigen, die Kommunikationsstrukturen der Organisationen, die sie aufbauen, widerzuspiegeln, spielt eine entscheidende Rolle bei der Strukturierung moderner Webentwicklung. Die Entwicklung von frühen Praktiken zu heutigen komplexeren Systemen wie Mikro-Frontends und komponentenbasierten Architekturen wurde weitgehend von diesem Prinzip geprägt. Indem wir uns ansehen, wie Anliegen in der Webentwicklung historisch getrennt waren, können wir besser verstehen, wie aktuelle Praktiken entstanden sind und warum sie so aussehen, wie sie heute aussehen.

In den Anfängen der Webentwicklung waren oft verschiedene Teams für bestimmte Technologien verantwortlich. Ein Team kümmerte sich um den HTML-Code, ein anderes um CSS und ein weiteres Team um JavaScript und serverseitige Logik wie PHP. Diese klare Trennung der Verantwortlichkeiten oder „Trennung der Anliegen“ wurde durch die unterschiedlichen Fähigkeiten jedes Teams vorangetrieben. Designer übergaben pixelgenaue Photoshop-Dateien an ein Team, das diese dann in HTML- und CSS-Vorlagen umwandelte. Sobald die Vorlagen fertig waren, integrierte das nächste Team sie in die App, wobei es oft zu Reibungsverlusten kam, wenn etwas nicht perfekt passte.

Ein Designer könnte eine .psd-Datei liefern, in der alle neun Ecken einer Tabelle sorgfältig gestaltet sind, und das HTML/CSS-Team würde sie in ein funktionierendes Layout schneiden. Sie waren jedoch weitgehend von der eigentlichen Logik oder den Benutzerinteraktionen der App abgekoppelt. Ihre Aufgabe bestand lediglich darin, sicherzustellen, dass die visuelle Darstellung funktionierte. Das Backend-Team, das sich mit PHP und JavaScript beschäftigte, integrierte dann diese statischen Vorlagen in die funktionierende App und stellte oft fest, dass die von den früheren Teams präsentierten Lösungen nicht ideal für die Anforderungen der Anwendung waren. Dies spiegelte die Strukturierung von Organisationen wider, wobei jedes Team für einen anderen Teil des Prozesses zuständig war, ohne dass es viel gegenseitige Kommunikation gab.

Der Wandel zur komponentenbasierten Architektur

Heute hat sich die Art und Weise, wie wir Anliegen trennen, dramatisch verändert. Anstatt die Verantwortlichkeiten nach Technologie aufzuteilen – etwa ein Team für HTML und CSS und ein anderes für JavaScript und PHP – sind moderne Teams eher für den gesamten Stapel spezifischer Teile der Anwendung verantwortlich. Normalerweise besitzt jedes Team einen vertikalen Teil der Anwendung, der alles von den Frontend-Komponenten bis zur Backend-Logik umfasst. Dieser Wandel wird durch den Aufstieg komponentenbasierter Architekturen vorangetrieben, bei denen wiederverwendbare, in sich geschlossene Komponenten die Bausteine ​​des Systems sind.

Statt beispielsweise ein Team, das sich auf das gesamte HTML und CSS auf der gesamten Website konzentriert, und ein anderes Team, das sich um JavaScript und die serverseitige Integration kümmert, haben Sie jetzt Teams, die für bestimmte Funktionen oder Komponenten verantwortlich sind, wie zum Beispiel < ;Article>, oder . Jedes Team verwaltet seine Komponente oder seinen Teil der Anwendung von oben bis unten, einschließlich der Frontend- und Backend-Logik. Dies ermöglicht es den Teams, autonomer zu arbeiten, wodurch Engpässe und Missverständnisse reduziert werden, die im alten Trennungsmodell häufig auftraten.

Diese neue Trennung der Belange nach Funktion oder Komponente statt nach Technologie ermöglicht es Teams, schneller zu iterieren. Ein Team, das beispielsweise für ein Chat-Widget verantwortlich ist, kann Änderungen sowohl an der Benutzeroberfläche als auch an der Backend-API implementieren, ohne darauf warten zu müssen, dass ein anderes Team einen Teil des Systems übernimmt. Der Hauptunterschied besteht nun darin, dass es statt spezialisierter Teams, die sich nur auf HTML oder JavaScript konzentrieren, funktionsübergreifende Teams gibt, die die Verantwortung für ihre Komponenten oder Funktionen in ihrer Gesamtheit übernehmen.

Mikro-Frontends und unabhängige Teamverantwortung

Eines der bedeutendsten Ergebnisse dieser Verschiebung ist der Aufstieg von Mikro-Frontends, bei denen verschiedene Teams unterschiedliche Teile des Frontends besitzen, genau wie sie Teile des Backends besitzen. Dies ermöglicht ein Maß an Unabhängigkeit, das in der Anfangszeit nicht möglich war. Eine Mikro-Frontend-Architektur spiegelt die Unabhängigkeit wider, die Teams jetzt bei der Verwaltung ihrer Komponenten haben.

Zum Beispiel hat ein Team, das für könnte alles besitzen, von der UI-Struktur bis hin zur Interaktion mit den von APIs abgerufenen Daten. Ein weiteres Team, das für

Sie haben die volle Kontrolle darüber, wie Artikel abgerufen, gerendert und mit ihnen interagiert werden, von der Frontend-Logik bis hin zu Datenbankabfragen. Dieses Maß an Autonomie bedeutet, dass Änderungen unabhängig umgesetzt werden können, ohne dass eine Abstimmung mit anderen Teams wie in der Vergangenheit erforderlich ist.

Im Gegensatz dazu erforderten Änderungen an jedem Teil des Systems im alten HTML-CSS- vs. JS-PHP-Trennungsmodell eine Koordination zwischen mehreren Teams. Wenn das Frontend eine neue Funktion benötigte, musste das HTML/CSS-Team mit dem JavaScript-Team zusammenarbeiten, um sicherzustellen, dass das neue Layout oder die neue Funktionalität wie beabsichtigt funktioniert. Da Teams heute von oben bis unten Eigentümer spezifischer Komponenten oder Funktionen sind, ist dieser Bedarf an teamübergreifender Koordination deutlich geringer, was schnellere Entwicklungs- und Bereitstellungszyklen ermöglicht.

Conways Gesetz in Aktion

Conways Gesetz bleibt so aktuell wie eh und je. Die Art und Weise, wie wir heute Software entwickeln, spiegelt immer noch die Art und Weise wider, wie unsere Teams organisiert sind. Der Unterschied besteht jedoch darin, dass moderne Teamstrukturen stärker auf Funktionen ausgerichtet sind und weniger auf Technologie isoliert sind. Die alte Methode der Aufteilung der Verantwortlichkeiten nach Technologie (HTML CSS vs. JS PHP) ist einem Modell gewichen, bei dem jedes Team für ein komplettes Feature oder eine komplette Komponente verantwortlich ist.

Diese moderne Interessenstrennung ermöglicht eine bessere Kommunikation innerhalb der Teams und eine gezieltere Eigenverantwortung. Mikro-Frontends, komponentenbasierte Architekturen und funktionsorientierte Teams spiegeln allesamt Conways Erkenntnis wider: dass Ihre Software unweigerlich die Struktur Ihres Teams widerspiegeln wird. Mit der Weiterentwicklung unserer Teamstrukturen entwickeln sich auch die Systeme, die wir aufbauen, und werden flexibler, modularer und unabhängiger.

Abschluss

Der Wandel von der technologiebasierten Trennung von Belangen zur funktionsbasierten Trennung hat die Art und Weise, wie wir Webanwendungen erstellen, revolutioniert. Conways Gesetz erklärt, warum diese Entwicklung stattgefunden hat: Da die Teams autonomer und funktionsorientierter geworden sind, hat sich die Architektur unserer Systeme diesem Beispiel angeschlossen. Mikro-Frontends, interne Komponentenbibliotheken und komponentenbasierte Entwicklung spiegeln alle den modernen Bedarf an unabhängigen, funktionsübergreifenden Teams wider, die sowohl das Frontend als auch das Backend ihrer spezifischen Funktionen oder Komponenten besitzen.

Obwohl sich die Tools und Frameworks weiterentwickelt haben, bleibt das Grundprinzip dasselbe: Die Art und Weise, wie Teams strukturiert sind, hat direkten Einfluss auf die Software, die sie erstellen. Durch das Verständnis von Conways Gesetz und der Geschichte der Trennung von Belangen können wir die Systeme, mit denen wir heute arbeiten, besser einschätzen und vorhersehen, wie sie sich weiterentwickeln könnten.

Das obige ist der detaillierte Inhalt vonConways Gesetz und Trennung von Belangen in der Webentwicklung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!