| 

.NET C# Java Javascript Exception

4
Wenn man in letzter Zeit die Schlagzeilen verfolgt, dann sind es Themen wie die Event Based Components von Ralf und jede Menge Patterns, die Stefan der Community durch Dojos beizubringen versucht, die die Fachzeitschriften prägen.

Grundsätzlich sind die Aussagen dabei: Ohne eine Trennung der Verantwortlichkeiten, durchgängige Komponenten-Tests, Einhaltung des OCP und lose Kopplung - erreicht durch z.B. die EBC - endet die schönste grüne Wiese bald in einer braunen Schlammlandschaft.

Was aber, wenn man sich im Kundenprojekt mit einer solchen konfrontiert sieht?

Legacy Code ist meist in Form von mehreren Jahren zu einem großen, braunen Klumpen "gereift". Und das bestimmt nicht, weil sich die Entwickler hervorragend mit Entwicklungsmustern auskennen. Da die Entwicklung aber i.d.R. nicht mal eben für 2 Jahre gestoppt wird, um die gesamte Code Base auf Links zu ziehen, stellt sich die Frage, wie geht man am geschicktesten damit um?

Die Entwickler sind häufig nicht die jüngsten, vereinen aber das gesamte Fachwissen in sich. Ergo: Austauschen geht nicht. Alte "Paradigmen" sind eingeprägt und es fällt einem sehr schwer, den Vorteil einer SoC oder OCP zu erklären (was auch nicht besonders erstaunlich ist...). Natürlich möchte man aber weitere "Entgleistungen" vermeiden. Und nun?

Hat jemand ein Beispiel für ein erfolgreiches Refactoring einer bestehenden Legacy Applikation, die hinterher die Regeln unserer geliebten Entwicklungsmuster einhielten? Oder hat gar jemand damit begonnen, die EBC tatsächlich in einem produktiven Programm (das sich nicht gerade in der Neuentwicklung befindet) umzusetzen?

Zu deutsch: Wie macht ihr aus Braun Grün? Und ist wirklich alles Grün, was uns heute als solches "verkauft" wird?
News:
15.02.2011
1
Die Überschrift ist mieß
Floyd 15.02.2011
@Floyd man muss nicht alle politisch interpretieren
Hendrik Lösch 15.02.2011
1
Meine Meinung ist nur, wenn jemand das selber Problem hat, wird er diesen Beitrag über sie Suchfunktion nur schwierig finden.
Floyd 15.02.2011
1
Ok, dann habe ich zuviel politisiert. War auch eher als Witz gedacht ;)
Hendrik Lösch 15.02.2011
EBC: Event-Based Components, geht noch aus dem Text hervor
OPC: vermutlich Open-Closed-Principle, aber da muss man schon raten
SoC: ???
Matthias Hlawatsch 16.02.2011
SoC - Separation of Concerns
Hendrik Lösch 16.02.2011
5 Antworten
10
Eine Anmerkung vorab:

Wenn man in letzter Zeit die Schlagzeilen verfolgt, dann sind es Themen wie die Event Based Components von Ralf und jede Menge Patterns, die Stefan der Community durch Dojos beizubringen versucht, die die Fachzeitschriften prägen.


Möglicherweise haben die anderen Entwickler auch in den letzten 10 Jahren die Schlagzeilen verfolgt, aber den Fehler gemacht, jeden neuen in einer Fachzeitschrift angepriesenen Hype sofort in die Software zu giessen. Auf diese Art und Weise entsteht auch sehr schnell eine Wartungswüste (so schon gesehen in einem Projekt, an dem man die letzten 15 Jahre IT Hype Geschichte im Source Code "nachlesen" konnte). Sprich: Wartungsfreundlichkeit wurde auch schon vor 25 Jahren versprochen.

Ansonsten ist es gut, eine "alles oder nichts" Denkweise zu vermeiden. Sprich: Die Welt wird auf vielen Wegen ein wenig grüner.

Womit man bspw. anfangen kann ist, einzelnen, oft verwendeten Objekten eine zentrale "Factory" zu verpassen. Und dann, wenn auf dem Objekt eine neue Operation durchgeführt werden soll, diese in eine Komponente zu faktorieren. Falls man dann noch ein wenig Zeit übrig hat, kann man eine weitere Methode mit umziehen.

Auch sehr empfehlenswert: Ersetze konkrete Klassen durch Interfaces und schreibe Adapter, falls Du noch einen "Lavastrom" am Leben halten muss (typisches Beispiel: 20 Reports greifen auf eine "alte" Lösung zu, aber 5 Sachen können schon mal "sauber" auf eine neue Architektur gezogen werden). Natürlich bringt es nichts, wenn Du nun in dem Projekt für ein halbes Jahr 5 Sachen in einer neuen Methode entwickelst, und die 20 anderen Dinge dann die nächsten 5 Jahre nicht mitgezogen werden. Dadurch machst Du - ohne es zu wollen und mit eigentlich besten Absichten - nur alles noch schlimmer. Dann kommt in 3 Jahren ein neuer Entwickler, mit einem neuen Hype (sagen wir mal "fraktales Refactoring mit automatischen Source Agenten" ;-)), der dann wieder 5 Teile von den 25 umzieht, und ihr habt schon wieder eine ganze Schar an Paradigmen in einem einzigen Projekt.

Ergo: KISS - Keep It Simple and Stupid. Überlege Dir, wir Du die Anforderungen sauber umsetzen kannst. Schreibe Dir Factories und Adapter, implementiere Interfaces, aber gib auch eine strategische Managementempfehlung, dass die anderen Objekte / Seitenstrassen mit umgezogen werden sollten (wegen oben beschriebener Entropie).
15.02.2011
CRegenschein 645 2 9
Sehr treffend geschrieben.
Hendrik Lösch 15.02.2011
1
Ich stimme da überein. Besonders, weil diese Antwort zur Vorsicht mahnt.

Üblicherweise wurden Alt-Anwendungen nach Paradigmen entwickelt, die zur damaligen Zeit am sinnvollsten erschienen. Und solange die Architekturvorgabe sauber beibehalten wird, ist die Anwendung auch relativ gut wartbar. Man gewöhnt sich sehr schnell daran. Das ursprüngliche Design ist ja nicht schlecht an sich, sondern höchstens anders.

Ein stückweises "Besser"-machen führt meiner Erfahrung nach aber immer(!) in ein Wartungsfiasko, weil etliche Design- und Stilmittel in einer Anwendung vermischt werden.
Andreas Ganzer 07.03.2012
2
Oder hat gar jemand damit begonnen, die EBC tatsächlich in einem produktiven Programm (das sich nicht gerade in der Neuentwicklung befindet) umzusetzen?


Du meinst, ob jemand ein Refactoring in Richtung Event-Based Components versucht hat? Es würde mich sehr wundern, und noch mehr, wenn es von Erfolg gekrönt war (aber ich lasse mich gern belehren). Ich wäre selbst bei einer Neuentwicklung noch sehr vorsichtig. Schon allein, weil das Tooling für die Platinen noch in den Kinderschuhen steckt (ohne in Abrede stellen zu wollen, dass sich da schon einiges bewegt). Der ganze Ansatz wirkt auf mich derzeit noch sehr "experimental" - im besten Sinne: man kann eine Menge daraus lernen, und er wirft ein erhellendes Licht auf die Art und Weise, wie wir derzeit Software entwicklen.

Wenn Du ein neues Projekt anfängst, Dir von EBC einen echten Mehrwert versprichst und auch die Risiken einschätzen und beherrschen kannst (Lehrgeld, Neuland, Pionier...), spricht auch prinzipiell nichts dagegen, diese Architektur einzusetzen. Nur: tu es nicht, einfach weil gerade viel darübr geschrieben wird.

Ansonsten aber kann ich CRegenschein nur zustimmen: um ein Schlammfeld in eine grüne Wiese zu verwandeln, brauchst Du keine EBC oder irgendein anderes bestimmtes Pattern / Technologie / Architektur, und schon gar nicht sollte die Verwendung desselben das (Haupt-)Ziel sein. Wichtig ist vor allem, die Wartbarkeit, also Verständlichkeit und Änderungsfreundlichkeit des Codes zu verbessern. Dabei können Dir Pattern helfen, aber sie sind kein Selbstzweck. CRegenschein hat gute Tips gegeben, und Ralf Westphal hat in der dotnetpro nicht nur über EBC geschrieben, sondern hatte letztes (oder schon vorletztes?) Jahr dort auch eine schöne Serie über Refactoring. Schau da mal rein.
16.02.2011
Matthias Hlawatsch 13,2k 4 9
2
Zum Thema CCD in Brownfieldprojekten gibt es bei Heise eine schöne Artikelserie von Ralf und Stefan. Dort findet man auch viele Ideen und Hinweise, wie man in Brownfieldprojekten wieder Herr der Lage werden kann.

Start der Artikelserie
16.02.2011
Andreas Richter 1,7k 1 2 8
0
Um ein Brownfield trocken zu legen, braucht man keine EBC/Flow Design. Die existierende Trockenlegungsliteratur kennt diese Begriffe ja auch nicht. Irgendwie geht es auch anders. Einfach klein-klein mit Refactorings und CCD-Prinzipien rangehen... das wird schon. Irgendwann. Irgendwie.

Ich ziehe es aber vor, es systematischer zu versuchen. D.h. ein Zielsystem zu entwerfen und darauf hin zu refaktorisieren. Und da ich Entwürfe nur noch mit Flow Design mache (was keine Übersetzung nach EBC erzwingt), halte ich den Weg für sehr vorteilhaft. Wenn schon neu, dann richtig.

Aber ist Flow Design "richtig"? Ist es praktikabel? Nun, ich tue es jeden Tag und bin noch auf keine Grenze gestoßen. Was ich mit OOAD sehr leicht schlecht machen kann, kann ich mit Flow Design leichter besser machen. Und skaliert das? Auf der VSone habe ich gerade jmd getroffen, dessen 12-Personen Team komplett und voll auf EBC setzt. Jeden Tag. Und der sagt, "It just works." Demnächst werden sie die restlichen 18 im Team auch noch "umpolen". Dann sind 30 Leute mit EBC/Flow Design am arbeiten. Warum? Weil es funktioniert und besser funktioniert als alles, was sie vorher versucht haben.

Wer nicht will, muss ja aber kein Flow Design machen. 15 Jahre Objektorientierung haben keine durchschlagenden Erfolge in der Wartbarkeit gebracht - da kann man auch noch ein paar Jahre länger warten ;-)
19.02.2011
Ralf Westphal 765 1 4
0
O.T.
Angesichts der Tatsache das EBC so neu und das Verdrahten gewöhnungsbedürftig ist freue ich mich über jede Aussage zu EBC im wirklichen Leben. Ich würde mir mehr Berichte aus der praktischen Anwendung wünschen. Das Konzept ist gut aber bisher weiß ich nur von "Laboranwendungen", Projektarbeit hat aber ihre eigenen Tücken.
22.02.2011
Richard 391 7

Stelle deine Ebc-Frage jetzt!