Big Ball of Mud / 7

Na, ein kleines Zitat aus Big Ball of Mud geht noch, oder? Ist auch ganz kurz:

Das rituelle Zurschaustellen von "Cleverness" verbessert oft den Rang in der Programmierer-"Hackordnung" eher als handwerkliche Merkmale wie Einfachheit oder Klarheit. Und so gedeiht das, was glorifiziert wird.

Alles klar?

Meine erste C# Windows Applikation!

Weiß nicht, wie ich da heute draufgekommen bin, vielleicht weil hier so lustig stand:

Lernen Sie, wie Visual Studio Express Editions Ihnen helfen können, Spaß bringende, coole Projekte zu erstellen, die Sie auf Ihrem Windows Desktopclient ausführen können.

Ja, ja, "Ihnen helfen können"! Wie war das: Da wird Ihnen geholfen? Aber das macht einen schon ein wenig heiß: "Spaß bringend", "coole Projekte".... Also, runtergeladen, installiert, gestartet, und dann noch in der Hilfe das gefunden: "How to: Build a C# Application in 60 Seconds", und schon war das Windows Forms Hello World fertig:

private void button1_Click(object sender, EventArgs e)
{
   label1.Text = "Hello, World!";
}
Supercool, oder?

Big Ball of Mud / 6

Nachtrag zu Big Ball of Mud / 5: Lt. eines englischen Muttersprachlers ist "the most complicated system that can possibly work" sowas wie "das komplizierteste System, das gerade noch funktioniert", was auch irgendwie Sinn macht.

Und gleich weiter, die nächsten schönen Zitate:

Solche Programme können eine persönliche Festung werden, die zwar selbst der Autor kaum noch verstehen kann, jeder andere aber noch viel, viel weniger. Und sobald simple Reparaturen am Programm Tagesbeschäftigungen werden, verwandelt sich das Programm in einen Sumpf. Es wird für das Management zunehmend schwierig vorherzusagen, wie lange diese Reparaturen eigentlich dauern sollten. Dinge, die simpel zu bewerkstelligen sein sollten, ähneln eher einem nicht enden wollenden Schützengrabengefecht. Alle müssen sich in dieses absurde Tempo fügen. Manche finden sogar Gefallen daran, verstecken sich in ihren gemütlichen Höhlen, und machen ihre "Zwei-Zeilen-pro-Tag"-Reparaturen.

Big Ball of Mud / 5

Systeme werden rasch komplizierter, allerdings nur bis zu einem gewissen Punkt:

Die Antriebskräfte für die Evolution solcher System sind bisweilen pervers. So wie es einfacher ist geschwätzig zu sein, als präzise, ist es leichter komplexe Systeme zu schaffen als einfache. Dafür begabte Programmierer können Komplexität schneller schaffen als ihre Kollegen, und schneller als sie sie dokumentieren und erklären können. Und so wie eine Armee ihren Logistikzug abhängt, steigert sich die Komplexität bis zu dem Punkt, wo dieselben Programmierer gerade nicht mehr damit klar kommen.

Dies wird manchmal auch als "Peter Prinzip" der Programmierung bezeichnet. Komplexität steigert sich schnell bis zu einem Grad, an dem Programmierer gerade nicht mehr damit zurecht kommen. An diesem Punkt geraten Komplexität und unsere Fähigkeiten in ein ungutes Gleichgewicht. Der Blitzkrieg verwandelt sich in eine Niederlage. Wir schufen das komplizierte System, das gerade noch funktionieren kann.

Mann, da ist noch viel verbesserungswürdig! Wie sagt man auf gut Deutsch: Das komplizierteste System, das "can possibly work". Das womöglich funktionieren könnte?

Big Ball of Mud / 4

Und noch etwas aus dem Big Ball of Mud-"Pattern":

Und letztendlich unterscheiden sich Programmierer in ihren Fähigkeiten und ihrem Engagement für Architektur. Leider wurde Programmarchitektur so lange gering geschätzt, dass viele Programmierer den Big Ball of Mud als Normalfall ansehen. Manche Programmierer sind auch besonders begabt sich in diesen Sümpfen zurecht zu finden und andere durch sie zu führen. Irgendwann kann die Symbiose zwischen Programmarchitektur und Fähigkeiten das Wesen einer Organisation selber verändern, und Sumpfführer wertvoller als Programmarchitekten werden. Undurchschaubarer Code kann dann sogar einen echten Wettbewerbsvorteil für die bringen, die sich in dem Kladeradatsch noch zurecht finden. In einem Land ohne Grenzsteine, ohne Markierungen werden solche Führer überlebenswichtig.

Big Ball of Mud / 3

Ich hatte ja hier und hier schon ein paar Übersetzungsversuche von "Big Ball of Mud" probiert. Wie wäre es andererseits mit

• "Riesenklumpatsch" (steckt Klumpen und Matsch zugleich drin), vielleicht auch verwegen gesteigert als "Gigantischer Riesenklumpatsch"?!
• Oder vielleicht "Riesenschlamassel" (da hätten wir Schlamm und Masse drin)?
  
• Gigantischer Riesenschlamassel?
  
• Vielleicht noch Code dazu? Codeklumpatsch?
• Riesencodeklumpatsch?
• Finaler Codeschlamassel?
• Gigantischer Riesencodeschlamassel?
• Riesenklumpatsch an Code?
• Riesenklumpatsch matschigen Codes?
  

Big Ball of Mud / 2

Was gibts noch Schönes im Artikel Big Ball of Mud? Wie sollte man Big Ball of Mud jetzt übersetzen? "Großer Klumpen Matsch" oder "Riesenklumpen Matsch"?

Wie schaut nun der matschige Code für einen Programmierer an der Front, der sich damit beschäftigen muss, aus? Datenstrukturen sind sehr willkürlich gewählt, oder so gut wie nicht vorhanden. Alles hat mit allem zu tun. Jeder Teil des Programms "spricht" irgendwie mit jedem anderen. Wichtige Zustandsdaten sind ausnahmslos global. Manche könnten dies als eine Art "Blackboard"-Ansatz betrachten, aber es gleicht mehr einem Wühltisch an undifferenzierten und wahllosen Zustandsarten. Wo Zustandsinformationen einigermaßen örtlich abgegrenzt sind, werden sie hemmungslos über byzantinische Hintertüren ausgetauscht, und unterminieren so die eigentliche Struktur des Systems.

Variablen- und Funktionsnamen sind nicht informativ, oder sogar irreführend. Funktionen selber machen ausgiebigen Gebrauch von globalen Variablen, und von langen Listen mäßig definierter Parameter. Die Funktionen selber sind lang und verwickelt, und machen verschiedenste Dinge, die nichts miteinander zu tun haben. Der Programmablauf ist schwer zu verstehen und schwierig nachzuvollziehen. Die Absicht des Programmierers ist so gut wie nicht zu erkennen. Der Code ist schlichtweg unlesbar, und grenzt an Unentzifferbarkeit. Der Code zeigt alle Anzeichen fortwährender Patche verschiedenster Programmierer, von denen keiner so recht die Konsequenzen seiner Änderungen abschätzen konnte. Haben wir eigentlich schon Programmdokumentation erwähnt? Welche Dokumentation?

Großer Matschklumpen? Riesenmatschklumpen?

Big Ball of Mud

Hatte ich vor Jahren schon mal gelesen, dann wieder vergessen, und jetzt zu passender Gelegenheit wieder auf diesen wunderbaren Artikel über das verbreitete "architectural pattern" "Big Ball of Mud" gestoßen. Ich versuche mal, ein paar Sätze ansatzhalber auf Deutsch zu übersetzen:

Ein "Großer Haufen Matsch" ist ein willkürlich strukturierter, ausufernder, schludriger, notdürftig mit Tesa und Maschendraht zusammengehaltener Dschungel von Spaghetti Code. Wir haben ihn alle schon gesehen. Diese Systeme zeigen offensichtliche Merkmale von unkontrolliertem Wildwuchs und ständigem Herumgeflicke. Weit entfernte Teile des Systems teilen sich zügellos Daten, meistens so weitgehend, dass fast alle wichtigen Daten global oder dupliziert sind. Eine übergreifende Struktur des Systems wurde womöglich nie definiert. Falls schon, ist sie bis zur Unkenntlichkeit erodiert. Programmierer mit einem Fitzelchen Gespür für Programmarchitektur gehen diesen Schlammlöchern tunlichst aus dem Weg. Nur die, die sich keinerlei Gedanken über Architektur machen, oder sich vielleicht eingerichtet haben mit der Tag für Tag gleichen Tretmühle des Stopfens immer neuer Löcher in diesen rissigen Dämmen, sind zufrieden damit an solchen Systemen zu arbeiten.