Tim ZöllerMar 3

Hot Take: Die Trennung von UI-Stack und Backend-Stack ist ein großer Grund, warum Softwarequalität die letzten Jahre abnimmt.

Gerade wieder eine Ausschreibung gesehen: Gesucht wird jemand mit Spring Boot Erfahrung, Angular / Typescript und Flutter.

Vielleicht bin ich ja auch ein bisschen langsam, aber Java, Spring Boot und das ganze Ökosystem sind komplex. Ich kann mir einfach nicht vorstellen, diese drei Technologien ähnlich tief zu verstehen und bei den Entwicklungen mitzuhalten

Show threadOliver DrotbohmMar 3
@javahippie Ist das nicht eher konsequent der völlig widersinnigen Entscheidung, diese Teams zu trennen?
Show threadTim ZöllerMar 3
@odrotbohm Da würde ich nachfragen wollen, was "Teams zu trennen" bedeutet. Front- und Backenddevs in zwei verschiedenen organisatorischen Einheiten? Oder die Skills in einem Team klar aufzutrennen?
Show threadOliver DrotbohmMar 3
@javahippie Siehe die andere Antwort an Nils und dich. Man will eigentlich keine separaten Teams, sondern Entwickelnde mit unterschiedlichen Expertisen. Als ich jung war ging das unter Schlagwort „Crossfunktionale Teams“ durch.
Show threadZappes

@odrotbohm @javahippie Das sehe ich tatsächlich anders. Für mich ist das UI Nutzer eines wohldefinierten Dienstes, der vom Back-End erbracht wird. Die Trennung finde ich nicht nur nicht problematisch, sondern extrem vorteilhaft für die Architektur.

Die Front- und Backend-Entwickler sollten organisatorisch trotzdem Teil eines crossfunktionalen Konstrukts sein, aber innerhalb dieses Konstrukts finde ich getrennte Entwicklung der Komponenten sehr vorteilhaft.

Mar 3 at 8:11amWeb
Show threadOliver DrotbohmMar 3

@zappes @javahippie Nehmen wir mal kurz an, das wäre so. Gibst du mir 1. recht, dass das Frontend das Backend braucht, um ein Feature (für die Enduser:in) schlussendlich zu liefern? Gibst du mir 2. recht, dass das Backend das Frontend braucht, um ein Feature zu liefern?

Wenn a && b, dann haben wir eine zyklische Abhängigkeit und das Ding ist quasi eins, weil die positiven Effekte der Trennung sich auf das Wohlfühly der Entwickelnden beschränken und alle anderen mit den negativen rumschlagen.

Show threadZappesMar 3

@odrotbohm @javahippie Meine persönliche Vorgehensweise als Architekt ist es, zunächst mal den zu automatisierenden Businessprozess zu verstehen und ordentlich zu dokumentieren - BPMN goes brrrrrr.

Von da aus geht es weiter zur Umsetzung des Frontends mit Mock-Services für das Backend, bis die UX zusammen mit den Anwendern stabilisiert wurde. Entwicklung der Services erfolgt dann parallel zur Frontenderstellung, wo Funktionen bereits klar genug sind.

Show threadZappesMar 3
@odrotbohm @javahippie Das gibt einem einerseits ein paar schöne, parallelisierbare Pipelines. Dann erzeugt es es wohldefinierte Services. Und man kriegt eine interne API, die gut genug ist, um das Frontend tatsächlich in verschiedenen Varianten bauen zu können - ggf. mit kleinen BFF dazu, die bestimmte Abfragemuster (meist für Stammdaten) in optimierter Form für das jeweilige UI liefern können.
Show threadOliver DrotbohmMar 3
@zappes @javahippie Ich glaube wir reden aneinander vorbei. Und ich fürchte, es bringt nichts, wenn wir nicht wirklich in den Dialog treten wollen (da waren zwei Fragen in meinem letzten Post).
Show threadZappesMar 3

@odrotbohm @javahippie Ich würde gerne mehr dialogen, aber 450 Zeichen sind verdammt knapp und wir schreiben gerade gleichzeitig. Mastodon ist da gerade kein perfektes Medium. 😕

Aber die beiden Fragen kann ich aus meiner Sicht beantworten: Ich behaupte, dass die Abhängigkeit existiert, aber nicht zyklisch ist. Diese Trennung in kaskadierte Serviceebenen ziehe ich seit Jahrzehnten erfolgreich durch, das erfordert nur manchmal etwas Umdenken.

Show threadOliver DrotbohmMar 3

@zappes @javahippie Wie kann sie existieren und nicht zyklisch sein? Klar kannst du Backend bauen wie nix und alle Nerds freuen sich. Das ist dann aber kein Feature was irgendwem Nutzen stiftet. Und solche Features nennen wir "Waste".

Immer schon so gemacht. Weiter so! 👋

Show threadZappesMar 3
@odrotbohm @javahippie Eigentlich hätte ich gerne was über die Reduktion von n:m auf n:1/1:m gesagt, aber der völlig unprovozierte Ad-Hominem-Einwurf, dass ich ja nur zu alt bin, um Dich zu verstehen, hat mir die Lust darauf restlos geraubt.
Show threadOliver DrotbohmMar 3
@zappes @javahippie Steht da nicht. Bezog sich auf „ziehe ich seit Jahren … durch“.
Show threadFelix 🇺🇦🚴‍♂️🇪🇺Mar 3
@zappes @odrotbohm @javahippie Bist du rein Architekt oder entwickelst du auch noch selbst an der Anwendung? Nur mal so als Frage.
Show threadZappesMar 3
@leobm @odrotbohm @javahippie Inzwischen bin ich schon froh, wenn man mich wenigstens mal an die Architektur lässt. Irgendwer hat mich mal als "Enterprise-Architekten" bezeichnet bund seitdem darf ich eigentlich nur noch darüber reden, was andere machen sollen. 😕
Show threadOliver DrotbohmMar 3
@zappes @javahippie Dieses "extrem vorteilhaft für die Architektur" fänd' ich mal spannend zu erörten. Ich habe nämlich das Gefühl, dass das ganz schnell umfällt wenn man es mal genauer betrachtet, bzw. gar nicht erst unreflektiert (ich beziehe das nicht auf dich) annimmt.
Show threadcomrad 🇪🇺Mar 3

@zappes @odrotbohm @javahippie das man das aufteilt selbstverständlich sonnig, gerade im Sinne der Modularisierung. Will man ein völlig neues Frontend bauen, so braucht man nur dieses ändern. Geht ja darum, ob eine Person beide Bereiche entwickeln können sollte.

Dummer Vergleich: ein LKW-Mechaniker kann bestimmt auch PKW reparieren, aber ob das sinnvoll ist und dessen Expertise nutzt?

Show threadOliver DrotbohmMar 3
@comrad @zappes @javahippie Sorry, aber das hat absolut nichts mit Modularität zu tun. Wenn dein Business ist, jede zweite Woche das Frontend zu wechseln, bitte. Das JS Ökosystem hat da sicher seinen Beitrag zu dem Mindset beigetragen. Gern nochmal: *niemanden*, absolut *niemanden* außer Softwareenwicklende interessiert, mit welchem Stack irgendein Front- oder Backend gebaut wurde. Siehe dazu: https://www.youtube.com/watch?v=co3acmgP2Ng
Domain centric? Why Hexagonal, Onion and Clean architecture are answers to the wrong question by Oli

YouTube
Show threadcomrad 🇪🇺Mar 3
@odrotbohm @zappes @javahippie den Enduser interessiert das natürlich nicht. Aber sich als Techniker muss die Wartbarkeit interessieren. Und da ist Modularisierung ein essentielles Tool.
Show threadOliver DrotbohmMar 3
@comrad @zappes @javahippie Richtig. Aber Layering ist das Gegenteil von Modularisierung. 🤷‍♂️