Je weniger Code desto besser?

Kommt drauf an. Wenn du performanten Code schreiben musst und an den Datenstruckturen etwas änderst, dann muss man schnell mal große Teile neu schreiben
 
RalphS schrieb:
Dann macht man entweder was falsch oder sollte sich Interfaces mal angucken. Klar, manchmal ist Neubau unumgänglich, aber das ist dann doch eher selten(er).
Ja, meistens hat man etwas falsch gemacht. Abstrahieren ist sehr schwierig, wenn man gerade ein konkretes Problem vor Augen hat, und dann abstrahiert man unter Umständen nicht genug, oder man hat falsche Vorstellungen davon, in welche Richtung sich die Entwicklung in Zukunft bewegt.
Und dann kommt der Zeitpunkt wo man wirklich etwas wiederverwenden will und man merkt, das es ohne Anpassungen eben nicht auf die neue Anforderung passt.

Schönes Beispiel ist eine Desktop Anwendung in eine Web-Anwendung zu überführen. Selbst wenn die Desktop Anwendung schön nach Model/View/Controller Konzept aufgebaut war, geht sie davon aus, dass diese Komponenten sehr eng gekoppelt sind, in einem Adressraum liegen und Kommunikation zwischen ihnen mit niedriger Latenz möglich ist. Dann ist es z.B. kein Problem für die Eingabeprüfungen in der Oberfläche direkt Methoden des Models aufzurufen. Das wird aber nicht mehr gut gehen, wenn man eine Web-Anwendung hat, wo sowas einen kompletten Roundtrip zwischen Front- und Backend benötigt.

Mal abgesehen davon, das natürlich der ganze Alte (z.B. Windows) Code des Frontends sowieso neu geschrieben werden muss und man zwischen Front-und Backend ganz andere Schnittstellenanforderungen hat.

Wir haben bei uns im Unternehmen auch früher große "aspektorientierte" Softwaresysteme gebaut, die auch versucht haben, jede Art von Redundanz zu vermeiden. Für jeden Aspekt gab es ein paar Klassen und genau diese mussten genutzt werden.

Der Weg von Client/Server mit Windows "Fat" Client in die Cloud mit Web-Frontend war mit dieser Architektur nicht möglich. Heute haben wir eher lose gekoppelte Services (ich lasse das Buzzwort "Micro" davor bewusst mal weg...) die von unabhängigen DevOps Teams entwickelt werden. Redundanz lassen wir bewusst zu.

Wiederverwendbarkeit streben wir nur noch bei ganz allgemeinen technischen Basisfunktionen (z.B. unserem GUI-Framework) an, nicht bei Funktionalität auf Ebene der Anwendungs-Domäne.
 
  • Gefällt mir
Reaktionen: KitKat::new()
KISS Prinzip beachten.
Eine einfache Lösung ist einer komplexen (kürzeren) immer zu bevorzugen.
 
Eben. Code sollte so geschrieben werden, dass er von jedem sofort ohne Probleme verstanden wird. Man sollte nicht zwanghaft alles abstrahieren und wegen SOLID alles unnötig komplex gestalten. Wenn es in absehbarer Zukunft nicht zu erwarten ist, dass man diese Flexibilität braucht, dann lässt man sowas bleiben. Ansonsten ist das Zeitverschwendung. (YAGNI Prinzip)
Lieber Code schreiben, der einfach und leicht anpassbar ist.
KISS + YAGNI > SOLID
 
  • Gefällt mir
Reaktionen: Boa-P
Zurück
Oben