Wichtigkeit von SW Architektur

[jobo]

Zitat von mm1256:

Architektur als Backend...wieso sind dann Programmiersprache und IDE "extrem austauschbar"? Also konkret: Welche Architektur-Merkmale oder -Eigenschaften müssen erfüllt sein, um diesen Austausch so "extrem" realisieren zu können? Das würde mich "extrem" interessieren.

Ich vermute, dass eine "klassische" 3 Schicht Architektur gemeint ist. Also Datenschicht, (Business)Logik und die (austauschbare) Darsstellungs-/Anwenderschicht, realisierbar über Interfaces für Daten, Befehle, also Rest, SOAP usw..
Total beliebig ist es natürlich nicht, sondern man geht davon aus, dass backend seitig die Services oder Daten konform zu gewissen Standards bereitgestellt werden. Letztlich definiert sich genau der Nutzen der "Austauschbarkeit" und damit Unabhängigkeit und Flexibilität an den verwendeten Interfaces, die Anzahl der Schichten bzw. das konkrete Produkt ist dann eben egal. Zumindest in der Theorie, in der Praxis eben dann, wenn beide Seiten des Interfaces dieses auch vollständig und fehlerfrei bedienen.

Interface Beispiel IMAP, es interssiert niemanden, welcher Provider, welche Software serverseitig läuft und es interessiert genausowenig, welcher Client, welches ClientOS, .. die Daten abfragt, solange beide IMAP sprechen.

P.S: hab die Antwort von mjustin übersehen.

[Sir Rufo]

Sehr unterhaltsam und lesenswert dazu ist
http://blog.cleancoder.com/uncle-bob...hitecture.html

[mm1256]

Hallo,

vielen Dank euch Beiden für die Antworten. Dass damit die 3-Schicht-Architektur gemeint sein könnte, hab ich mir auch schon gedacht, war mir allerdings nicht sicher. Denn, daraus die "extreme" Austauschbarkeit der IDE bzw. der Programiersprache abzuleiten, halte ich persönlich für etwas gewagt.

Eine 3-Schicht-Architektur ist wohl nicht extenzielle Grundvoraussetzung für irgend ein popeliges Kleinprojekt. Wenn es folglich um größere Projekte geht, dann wird der Austausch der IDE bzw. der Programmiersprache - egal ob beim Front- oder Backend - schon eine echte Herausforderung, an welcher sich wahrscheinlich schon einige SW-Hersteller etwas "verhoben" haben.

EDIT: @SirRufo Jetzt hab ich etwas mehr Ahnung davon, warum Manager so viel Gutes tun

[mjustin]

Zitat von mm1256:

Wenn es folglich um größere Projekte geht, dann wird der Austausch der IDE bzw. der Programmiersprache - egal ob beim Front- oder Backend - schon eine echte Herausforderung, an welcher sich wahrscheinlich schon einige SW-Hersteller etwas "verhoben" haben.

Großer Vorteil für weitgehend 'entkoppelte' Systemarchitekturen, deren Bausteine man dann leicht auf neue Programmiersprachen oder 'umfangreich renovierte' Programmversionen umstellen kann.
Wenn man es richtig angeht, kann man mit den Bausteinen dieser Architekturen dann auch Lastverteilung auf beliebig viele Server leichter umsetzen als mit monolithischen Lösungen.
Ich habe dazu vor längerer Zeit diese Präsentation gefunden, die das Thema locker angeht:
Dopplr: It's made of messages - Matt Biddulph
Ein lesenswertes Buch das darin empfohlen wird ist "Enterprise Integration Patterns"

[IBExpert]

Moin,

bin im Moment ein wenig dicht mit Arbeit, melde mich aber zu dem Thema noch, um meine Sicht der Dinge zu schildern und was ich generell mit Architektur meine

[HeZa]

Zitat von Sir Rufo:

Sehr unterhaltsam und lesenswert dazu ist
http://blog.cleancoder.com/uncle-bob...hitecture.html

Danke für die Info, das kannte ich noch nicht. Dieses fiktive Interview zeigt ganz gut welche Kräfte sich dem Software Architektur Gedanken in den Weg stellen.

Zitat:

But that means that you're going to have lots of interfaces, and lots of little implementation classes ...

Freie Übersetzung:
Aber das bedeutet ja, dass es ganz viele Schnittstelle (ala IPrintService = interface) gibt, die dann auch noch von ganz vielen kleinen Klassen implementiert werden müssen ...

Da habe ich schon viele Programmier kennengelernt, die von der objektorientiert Entwicklung überzeugt sind und dann sagen, "ach nee nicht noch ne Schnittstelle/Klasse, dass können wir doch auch gleich hier in dieser Methode lösen ..." oder was auch gerne kommt, "aber dann sehe ich gar nicht was passiert, dann muss ich mir jedes mal erst die eigentliche Implementierung suchen ...".

Wenn man sich dem Thema Software Architektur nähern will, dann schießt man meiner Meinung nach mit Begriffen wie MVC, 3-Schichten-Architektur, Micro-Services über das Ziel hinaus. Das sind vorgedachte Architektur Patterns, die im schlimmsten Fall einem Missbrauch nicht standhalten.

Ich gestehe ich lerne auch immer noch. Zur Zeit lese ich (passend zum Link) mal wieder "Clean Code" von Robert C. Martin. Da ich täglich mit Delphi Leagcy-Systemen arbeite deren Entwicklung teilweise mit Delphi3 begonnen wurde, brauch ich manchmal eine kleine Erinnerung um die "hohen" Ziele nicht aus den Augen zu verlieren.

Als ich das Buch zum ersten Mal gelesen habe, haben mir Aussagen wie:

• eine Klasse/Methode sollte nur eine Aufgabe haben
• für eine Klasse/Methode sollte es nur einen Grund geben sie ändern zu müssen

ganz schön "Angst" gemacht haben. Da schaut man sich dann seine eigenen Klassen/Methoden an und zählt mal wieviele Aufgeben die so haben: 5, 10? Dann überschlägt man wieviele Gründe es für Änderungen wohl geben könnte. 20, 50?

Zum Glück ist das schon eine Weile her, aber ich habe ja noch meine Leagacy-Projekte. Vor ein paar Monaten fand man da noch, sagen wir mal 10 Klassen mit mindestens einer Methode, die 30 Parameter hatten, meistens waren es die gleichen, in der gleichen Reihenfolge, aber natürlich nicht immer. Mein Highlight 30 Parameter, 50 locale Variablen, 1000 Zeilen Code.

Zum Glück sind die Dinge die einem helfen können bereits seit langem niedergeschrieben. Lesen und die Kraft finden die Ideen und Vorschläge umzusetzen muss man dann allerdings schon selbst. Leider hatte ich nie einen Kollegen, wie im fiktiven Interview, der weiß wovon er spricht.

[Dejan Vu]

Zitat von HeZa:

Wenn man sich dem Thema Software Architektur nähern will, dann schießt man meiner Meinung nach mit Begriffen wie MVC, 3-Schichten-Architektur, Micro-Services über das Ziel hinaus. Das sind vorgedachte Architektur Patterns, die im schlimmsten Fall einem Missbrauch nicht standhalten.

Das würde ich nicht so sehen: Die Standardpattern erleichtern dem Architekten doch die Arbeit. Ich vergleiche Softwareentwicklung immer mit dem Haus/Städtebau. Für eine Hundehütte und einen Geräteschuppen brauche ich keinen Architekten (jedoch Grundlagen der Statik, zumindest beim Schuppen), aber bei einem Bungalow sieht das schon anders aus. Der Architekt arbeitet mit bekannten Mustern, Baumaterialien, Normen etc. und entwirft damit den Bauplan, den Bauarbeiter (=Entwickler), idealerweise angeleitet durch Vorarbeiter (Lead) umsetzen.
Ein Bauarbeiter, der ein bekanntes Pattern (Fachwerk, Klinker) im Bauplan sieht, kann hier seine Fähigkeiten anwenden und weiter verbessern. Würde jeder Architekt sein eigenes Süppchen kochen, würde auch jedes Mal Mumpitz herauskommen. Genauso verhält es sich mit der Softwarearchitektur.
Für den Städtebau (=Enterprise/Systemarchitektur) benötige ich ganz andere Pattern (Infrastruktur, Straßen- und Verkehrsplanung etc.) Aber immer sollten Standards und bekannte Techniken verwendet werden.
Nur bei neuen Anforderungen sollten auch neue Wege gegangen werden.

Ebenso, wie der Profi-Bauarbeiter die richtigen Techniken draufhaben muss, sollte der Programmierer die SOLID-Prinzipien verinnerlicht haben. Natürlich wird man DI in einem kleinen Tool nicht verwenden, ebenso wenig, wie man für eine Hundehütte oder den Gartenpavillion die neuesten Erkenntnisse der Spannbetonbauweise anwendet.

[HeZa]

Zitat von Dejan Vu:

Ebenso, wie der Profi-Bauarbeiter die richtigen Techniken draufhaben muss, sollte der Programmierer die SOLID-Prinzipien verinnerlicht haben. Natürlich wird man DI in einem kleinen Tool nicht verwenden, ebenso wenig, wie man für eine Hundehütte oder den Gartenpavillion die neuesten Erkenntnisse der Spannbetonbauweise anwendet.

Mein reden. Bevor man sich mit MVC etc. befasst, sollte man z.B. die SOLID-Prinzipien verstanden haben, allein schon um die Motivation hinter MVC zu verstehen. Denn wie oft ist es schon passiert, dass sich jemand mit MVC befasst "hey MVC, da schwören ja alle darauf, muss ich mal ausprobieren" um dann einen Tag später zu sagen, "boah, MVC was ein Mist, hier ne Klasse schreiben, da ein Interface implementieren, da hau ich doch lieber meine DataSource aufs Formular und mein Grid und bin fertig".

Und manchmal muss man auch erst jahrelang schmerzhafte Erfahrungen machen um die Motivation für die "aufwendigere" Technik nachvollziehen zu können.

[Sir Rufo]

Es nützen einem aber weder die buntesten Bilder, die griffigsten Buttons, die schnellste Internet-Anbindung noch die performanteste Datenbank wenn die Anwendung falsch arbeitet.

MVC, MVVM, GUI, RDBMS, JSON, SOAP, HTTP, ......... kann man am Anfang getrost komplett vergessen.

Viel wichtiger ist es eben zunächst festzulegen, was soll wann wie passieren und wann darf es nicht passieren:

• Darf Benutzer A die Zahlung freigeben
• Darf diese Rechnung gelöscht werden
• Darf dieser Artikel verkauft werden
• Darf dieser Benutzer sich überhaupt anmelden
• Darf dieser Änderung vorgenommen werden
• ... usw. ...

Genau das sollte auch das Kernthema im Kundengespräch sein. Mit MVVM und Konsorten, weiß der idR eh nichts anzufangen (gut hört sich eben wichtig an).

Wenn diese Regeln dann definiert wurden, dann kann man den Rest der Anwendung (GUI, DAL) darum bauen.

Denn ob diese Anwendung nachher auf einem Webserver läuft oder nativ ist oder auf einem Mobile Device, diese Regeln müssen eingehalten werden, weil sonst die Anwendung ja nicht mehr das macht, was die eigentlich soll.

Im Prinzip liegen gewisse Dinge eh schon fest (es wird mit Delphi programmiert, als Framework nehmen wir FMX und der Kunde hat schon einen XY-Datenbank-Server den man benutzen kann, bzw. er bekommt einen weitern DB-Server denn mit der Wartung kennt er sich schon aus).

[sh17]

Und wenn man diese Regeln dann in Delphi oder was auch immer so programmiert, dass man kaum oder keine Abhängigkeiten zu LIBs oder RTLs erzeugt, dann ist es relativ einfach, das ganze in eine andere Sprache zu portieren. Weil die Grundsätze sind ja in den meisten Sprachen die selben (Schleifen, Objekte,....).