„Wenn ein Arbeiter seine Arbeit gut machen will, muss er zuerst seine Werkzeuge schärfen.“ – Konfuzius, „Die Gespräche des Konfuzius. Lu Linggong“
Titelseite > Programmierung > Conways Gesetz und Trennung von Belangen in der Webentwicklung

Conways Gesetz und Trennung von Belangen in der Webentwicklung

Veröffentlicht am 26.11.2024
Durchsuche:261

Conway

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 war ein Spiegelbild der Organisationsstruktur, 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 Bedenken 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, z. B. , oder . Jedes Team verwaltet seine Komponente oder seinen Teil der Anwendung von oben bis unten, einschließlich der Frontend- und Backend-Logik. Dadurch können Teams autonomer 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 könnte ein Team, das für verantwortlich ist, alles besitzen, von der UI-Struktur bis hin zur Interaktion mit den von APIs abgerufenen Daten. Ein anderes Team, das für

verantwortlich ist, hat 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 erforderlich ist wie in der Vergangenheit.

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. Heutzutage, da Teams 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 von Teams und eine gezieltere Eigenverantwortung. Mikro-Frontends, komponentenbasierte Architekturen und funktionsorientierte Teams spiegeln Conways Erkenntnis wider: dass Ihre Software unweigerlich die Struktur Ihres Teams widerspiegelt. 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.

Während 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.

Freigabeerklärung Dieser Artikel ist abgedruckt unter: https://dev.to/jlarky/conways-law-and-separation-of-concerns-in-web-development-4cfk?1 Bei Verstößen wenden Sie sich bitte an [email protected] um es zu löschen
Neuestes Tutorial Mehr>

Haftungsausschluss: Alle bereitgestellten Ressourcen stammen teilweise aus dem Internet. Wenn eine Verletzung Ihres Urheberrechts oder anderer Rechte und Interessen vorliegt, erläutern Sie bitte die detaillierten Gründe und legen Sie einen Nachweis des Urheberrechts oder Ihrer Rechte und Interessen vor und senden Sie ihn dann an die E-Mail-Adresse: [email protected] Wir werden die Angelegenheit so schnell wie möglich für Sie erledigen.

Copyright© 2022 湘ICP备2022001581号-3