Montag, März 12, 2007

Die Mächtigkeit der Gleichförmigkeit

An verschiedenen Stellen (z.B. erst vor ein paar Tagen hier) habe ich immer mal wieder behauptet, das Cobol-System, an dem ich als Student mitgearbeitet habe, sei besser strukturiert gewesen als viele der C++- und Java-Systeme, denen ich danach begegnet bin. Diese Aussage hat bei einigen Lesern zu Unverständnis bis Entsetzen geführt. Grund genug, der Sache einmal auf den Grund zu gehen.

Gilt diese Aussage generell für Cobol-Systeme?
Nein, definitiv nicht. Ich habe auch einige Cobol-Systeme gesehen, die deutlich schlechter strukturiert waren als viele Java-Systeme.

Liegt es daran, dass an die Java-Systeme viel höhere Anforderungen gestellt wurden also an die Cobol-Systeme?
Nein. Viele der Java-Systeme unterschieden sich nur dadurch von den Cobol-Systemen, dass sie eine grafische Benutzungsoberfläche mit Swing hatten. Und die ist in Java eher leichter zu programmieren als in Cobol alles von Hand für zeichenbasierte Oberflächen zu codieren. Und selbst wenn Swing die Sache erschwert hätte, hätte das nur Auswirkungen auf die oberflächennahen Teile des Systems haben dürfen und nicht auf die Gesamtstruktur.

Liegt es daran, dass das Cobol-System besonders klein und übersichtlich war?
Nein. Es handelte sich um eine komplette Warenwirtschaft mit Lagerverwaltung und Produktion. Das System ist von ca. 10 Leuten über 10 Jahre lang weiterentwickelt worden.

Liegt es daran, dass am Cobol-System besonders gut ausgebildete Entwickler gearbeitet haben?
Nein. Es gab kaum ausgebildete Informatiker im Team. Einer der Entwickler war vorher Koch und ein anderer Steuerfachgehilfe.

Woran lag es denn dann?
Das System hatte eine einfache Musterarchitektur, die sich durch das ganze System zog. Stammdatenprogramme, Dialog-Programme, Auswahl-Dialoge, Batch-Programme, Druck-Jobs wurden nach dem immer gleichen Schema entwickelt, dass über die Jahre entstanden ist.

Damit war jedem Entwickler bei einer neuen Anforderung sofort klar, wo welche Änderungen notwendig waren und auch, wie teuer diese werden würden. Schätzungen, die stark von den tatsächlichen Aufwänden abwichen, habe ich im Projekt nie erlebt.

Dabei sind natürlich unglaublich viele Redundanzen entstanden. Wenn man ein neues Stammdatenprogramm schreiben wollte, hat man sich ein existierendes Stammdatenprogramm geschnappt und dieses angepasst. Das war Wiederverwendung durch Copy&Paste in Reinkultur.
Und trotzdem hat es funktioniert. Dabei sind sich alle einig, dass das eigentlich unmöglich ist.

Ich glaube, der Grund ist in der Gleichförmigkeit zu suchen, die das System hatte. Redundanzen sind gar nicht so schlimm, wenn sie jedem klar sind. Wenn ich für das Hinzufügen eines Feldes 100 Stellen anpassen muss, ist das halb so wild, wenn mir
  1. klar ist, wo ich die 100 Stellen im Code finde und
  2. jede Änderung mechanisch durchführbar ist, gerade wg. der Gleichförmigkeit des Codes.
Steht so eine Änderung an, ist diese zwar langweilig, aber nicht aufwändig. 100 gleichförmige Änderungen in bekanntem Code macht man in 2-4 Stunden.

Für diese Änderungen ist neben der Gleichförmigkeit eine andere Eigenschaft wichtig: Minimale Abhängigkeiten. Wenn niemand von den geänderten Code-Stellen abhängt, besteht nur geringe Gefahr, durch die Änderungen etwas kaputt zu machen. Außerdem gibt es das Risiko des Ripple-Effekts nichts: Die Änderung bringt weitere Änderungen in abhängigen Code nach sich, die wieder Änderungen in abhängigem Code nach sich ziehen...

Das führt mich zu der These, dass die bessere Cobol-Struktur sich an nur einer Eigenschaft festmacht: Es gab in dem Cobol-System weniger und klarer definierte Abhängigkeiten als in vielen Java-Systemen.

Diese Eigenschaft hat man sich erkauft durch Redundanzen (geht in Cobol auch nicht wirklich anders). Offensichtlich konnte man mit den Redundanzen aufgrund der Gleichförmigkeit besser umgehen als mit Java-Strukturen, die weniger Redundanzen aber dafür größere Abhängigkeiten aufweisen.

Sollten wir also zu Cobol zurück? Auf gar keinen Fall!

Wir sollten uns aber bewusster werden, wie gefährlich Abhängigkeiten zwischen Systemteilen werden können und wie leicht man sich in OO-Programmiersprachen unentwirrbare Abhängigkeitsgeflechte schafft. Vielleicht sollten wir eher einmal gleichförmige Redundanzen zulassen, um damit Abhängigkeiten zu reduzieren?

Post bewerten

3 Kommentare:

Michael Hüttermann hat gesagt…

Interessante Punkte ... die insbesondere auch verdeutlichen wie wichtig es ist über den eigenen Java-Tellerrand hinauszuschauen ... Ich habe selbst drei Jahre mit Cobol ERP-Systeme entwickelt und diese Erfahrungen will ich nicht missen. Ich kann mir schon vorstellen, dass ggf. Leute von Deinem Post entsetzt sind, die nur Java kennen und dies undifferenziert als Silver Bullet für jedes erdenkliche Szenario anhimmeln?! :o Das Java API ist schon umfangreich aber wieviel J(2)EE Projekte gibt es, bei denen auch JSE reichen würde bzw. die viel zu technik-getrieben sind?! Manchmal ist die Komplexität auch hausgemacht z. B. mit EJB < 3 -- Missstände, die mit EJB 3 oder Frameworks wie Spring behoben werden. Du sprichst Swing an ... Swing ist so dermaßen flexibel und mächtig und nicht zuletzt deswegen auch komplex: Bis Du dort eine Code Contribution durchkriegst ... man glaubt gar nicht was es dort für verborgene Abhängigkeiten gibt ... Von Redundanzen halte ich wenig ... ich gehe generell aber einen pragmatischen Ansatz und glaube, dass ein vernünftiges Design mit hoher Kohäsion und loser Kopplung zusammen mit einem konsequenten Einsatz von gängigen Standards die Abhängigkeiten auf ein Minimum schrumpfen lässt. BTW: man vergisst häufig wieviele Systeme auch derzeit noch auf Cobol laufen.

Meine 12 Euro Cent ... zu einem schönen, anregenden Posting.

Michael Hüttermann

Bernd Schiffer hat gesagt…

Hi Stefan. Kannst Du mal ein minimales Codebeispiel für den sinnvollen Einsatz von "gleichförmige Redundanzen" geben, mit denen man "unentwirrbare Abhängigkeitsgeflechte" bekämpft? Ich blick's noch nicht, glaub' ich. Gruß, Bernd

Stefan Roock hat gesagt…

Hallo Bernd,
ich werde Deiner Aufforderung nachkommen. Das kann aber noch etwas dauern. Es fällt mir doch schwerer, mich an die Details zu erinnern, als ich ursprünglich dachte.

Viele Grüße,
Stefan