Praktikumsbericht

Mein letzer längerer Rant ist Ewigkeiten her (Es war das Resident Evil 4 Review von Anfang Mai!). Seitdem stand ich in der Uni ziemlich unter Stress. Das Semester hatte anfangs eigentlich versprochen, ziemlich lässig zu werden mit lediglich 3 Vorlesungen: Informationssysteme, Produktionswirtschaft und Theoretische Informatik. Nun ja, das Versprechen wurde nicht ganz eingehalten. Viele meiner Kommilitonen empfanden ganz ähnlich, auch ihre Stundenpläne waren recht locker, trotzdem war jeder am jammern, wie wenig er schaffen würde.

Die Schuld an meinem Dilemma schiebe ich jetzt mal allein dem Software-Praktikum in die Schuhe. Dabei handelt es sich um eine Veranstaltung, die laut DPO für das vierte Semster nicht nur empfohlen, sondern vorher garnicht möglich ist und folgendermaßen abläuft: Zu Semesterbeginn werden Gruppen von 8 Leuten zusammengewürfelt. Diese Gruppen müssen im Semester nach einem festen Zeitplan zwei vorher festgelegte und für alle Gruppen identische Projekte bearbeiten. Wie gesagt, die Veranstaltung ist für das vierte Semester angesetzt, und zwar deshalb weil dabei Dinge angewandt werden sollen, die wir in DAP1 (1. Semester, Java-Programmierung), Betriebssysteme (2./3. Semester, Nebenläufigkeit und Netzwerke) und Softwaretechnik (3. Semester, Software-Konstruktion mit UML). All diese Dinge wurden nicht nur in den Vorlesungen vorgestellt, sondern auch abgeprüft, das entsprechende Wissen also für das Sopra vorausgesetzt. Mein Glück wollte es aber, dass von den 7 (sieben!) anderen Personen in meiner Gruppe niemand

• Die Grundlagen von Java beherrschte
  Mir ist tatsächlich die Frage gestellt worden, was denn Exceptions seien. Ausgerechnet von jemandem, der DAP1 3 mal geschrieben hat! Herrgott, man kann sowas vergessen, ja, aber dann kann man sowas auch wieder nachgucken.
• Die Grundlagen von UML beherrschte
  Ich kann verstehen, dass man nicht weiss was oder wofür Stereoptypen in UML dienen; erstens weiss ich es selbst nicht, zweitens hab ich sie auch nie gebraucht. Ich halte eine Menge von dem UML-Zeug für überflüssig, weil viel zu detailliert, aber das eine Assoziation einer Variable/Objektreferenz entspricht und nicht dazu dient anzuzeigen, das Objekt A irgendwann mal mit Objekt B kommuniziert, sollte man schon begriffen haben. Genauso wie die Unterschiede zwischen Aggregation, Komposition und Assoziation
• Überhaupt schon mal irgendwas programmiert hat
  Eigentlich hatte ich immer gefürchtet, auf das Gegenteil zu treffen, Typen die programmieren können, aber von Informatik keine Ahnung haben. Hier hatten wir das andere Extrem. Wie kann man Informatik studieren, ohne sich vorher fürs Programmieren zu interessieren? Der Code der dann hinterher rauskam sah auch entsprechend aus. Wüster Stil, keine Kommentare, keine Struktur. Selbst die enorm mächtigen Code-Inspection Funktionen des genialen Eclipse haben mich am Ende nicht mehr durchblicken lassen, welche Methoden denn was machen.

Das schlimmste jedoch waren die folgenden Punkte:

• Einen vorlauten Schaumschläger im Team
  Einer der behauptet, Programmiererfahrung zu haben, dessen objektorientierter Javacode aber eher aussieht wie ein zusammengefrickeltes Perl-Script. Der meint “Wir machen das jetzt mit MVC”, aber keinen Schimmer hat, was MVC wirklich bedeutet, die leider völlig ahnungslosen im Team mit falschen Argumenten überzeugt und seinen Standpunkt hartnäckig solange verteidigt, bis sich die Leiterin der ganzen Veranstaltung genötigt sieht, einzuschreiten. Der so schlampig progammiert, dass er hinterher seinen eigenen Code nicht mehr lesen kann.
• Ein absoluter Mangel an der Grundfertigkeit, sich eigenständig Wissen anzueigenen
  Da ich vorher auch noch nie in Java gearbeitet habe, halfen mir die rudimentären Kenntnisse aus DAP1 natürlich nicht weiter. Was habe ich also getan? Mich hingesetzt und gelesen. Zu Beginn des Studiums habe ich mir das 1400-seitige Handbuch der Java Programmierung von Guido Krüger gekauft und den Kauf hinterher bereut: Für DAP1 brauchte ich von 1400 vielleicht 300 Seiten, 1100 waren nur Ballast im Rucksack. Im Sopra kam der Rest endlich zum Einsatz. Darüberhinaus war natürlich stundenlanges Suchen in der Java API und dem Sun Java Tutorial angesagt.
  Eine Menge Zeit ging also nicht direkt in das Projekt ein, sondern vor allem in das Studium, dem freiwilligen (mehr oder weniger) und selbstständigen Aneignen von Wissen. Ich frage mich, was die anderen aus der Gruppe sich eigentlich unter dem Begriff vorstellen…

Aber nochmal zu der MVC-Geschichte: Es ging beim ersten Projekt darum eine Umfrage zu modellieren und dann per GUI durchzuführen. Dazu wurde am Anfang ein UML-Modell entwickelt, mit Fragebogen, Frage, Umfrage, Antwort, Benutzer und allem was halt dazugehört. Als das Projekt näher Richtung Implementierung rückte, schlug mein Kollege vor, das Modell doch in MVC umzusetzen. Obwohl MVC zu einem der 3-4 vorgestellten Pattern in der Softwaretechnik-Vorlesung (!) gehörte, konnte mit dem Begriff keiner in der Gruppe etwas anfangen. Seiner Ansicht nach war unser View die GUI, unsere Models waren halt die Models und die Controller, tja, was sind die Controller. Ach ja! Na klar! Controllerklassen. Was macht der Kerl? Rupft sämtliche Methoden aus den Objekten und erzeugt zu jeder Klasse eine entsprechende Controller-Klasse, die wiederum nur Methoden enthielt. Was wir dann hatten war herrlich, wie früher bei Pascal. Records und Procedures. Daten und Programm. Objektorientierung war ohnehin immerschon irgendwie komisch… Um das letzte bißchen Objektorientierung also los zu werden, schlug mein Kollege vor, alle Operationen an einem Objekt nur noch vom jeweiligen Controller vornehmen zu lassen und den anderen Controllern keinen Zugriff mehr zu gewähren. Dazu mussten wir nur die Objektreferenzen durch numerische IDs ersetzen. Fertig! Das Resultat war mitleiderregend. Statt einem objektorientierten Programmes hatten wir jetzt ein klassisches Prozedurales. Statt Zeigern hatten wir Indizes. Hallo Steinzeit.

Mein Kollege verteidigte das ganze immernoch als perfektes MVC, weil ja jetzt Model und Controller entgültig getrennt waren. In mir kamen Bilder von toten siamesischen Zwillingen hoch. Endlich getrennt! Ich hatte zu dem Zeitpunkt schon lange aufgehört zu argumentieren. Das war mir die Sache einfach nicht wert, und funktioniert hat das Programm. Die Leiterin des Sopras war allerdings ebensowenig von dem Vorgehen angetan, im Gegensatz zu mir konnte sie aber einfach entscheiden, dass wir (dann aber blöderweise erst eine Woche vor der Präsentation) das Programm neu zu schreiben hatten). So denn…

Das sieht hier vielleicht harmlos aus, aber wenn ein Methodenrumpf zu 70% aus solchem Müll besteht, der meistens nichtmal wirklich erklärt was der Spaghetticode da gerade tut, kriegt man schnell Kopfschmerzen.

Jedenfalls. Ich hab sie machen lassen und mich weiter um die GUI gekümmert. 2 andere haben an der KI gefeilt. Mein Kollege und der Rest? Haben irgendwie nix mehr gemacht. Der Netzwerkstack mag vielleicht funktioniert haben, leider war keiner imstande, ihn vernünftig in das Programm zu integrieren. Also wurden per Brute Force alle Methoden der Spielengine (die für den Spielablauf übrigens rekursive Threads (!!! bis zu 600 pro Spiel!!!) statt eines Loops verwendet) in entsprechende Methoden für das Netzwerk gewrappt, so dass wir schließlich auf stattliche 43 Methoden kamen. Am Ende hatte aber irgendwie keiner mehr Lust die zu implementieren. Was übrig blieb erinnerte an das Klonlabor aus Alien 4. Natürlich hat mein Kollege keinen Finger mehr krumm gemacht, nur gesagt er hätte keine Lust mehr und würde auch durch das Programm nicht mehr duchblicken. Seinen eigenen Code…

Hätte mir ja alles egal sein können, wenn das Hauptprogramm nicht inwischen voll mit Bugs gewesen wäre, die dank komischer Tricks mit Threads auch die GUI beeinträchtigten. Also habe ich die letzten drei Wochen des Semsters jede Nacht vor dem Debugger verbracht. Schonmal jemand versucht, nebenläufige Programme mit 600 Threads zu debuggen? Es ist theoretisch möglich, aber es ist keine Vergnügen…