Smalltalker Jones und das heilige Image


Nein, wir sind hier nicht auf der Suche nach einem Titel für den nächsten Indiana Jones – Film, sondern ich verspüre das Bedürfnis, ein tückisches Anti-Pattern vieler alten Smalltalk-Projekte anzuprangern und zur körperlichen Gewalt anzustacheln:

Schlachtet das Heilige Image!!!

 Was ist denn jetzt wieder los mit dem Typ? Ich will es Euch gerne sagen…

Es ist mir schon in mehreren Smalltalk-Projekten begegnet, das heilige Image.

Ich meine damit ein auf einem Server schlummerndes Smalltalk-Image, das als Grundlage für einen Entwicklerarbeitsplatz und den des Runtime-Bauers (oder auch Packagers) dient. Niemand weiss mehr so genau, wieso es das heilige Image gibt, wer es mal angelegt hat, und was er so alles da hineingeladen hat. Oft ist es 40 oder 50 Megabytes groß und ist das Großartigste, was die alten Vorväter des Projekts hinterlassen haben. Dem Image wird gehuldigt und das Aufsetzen eines neuen Entwickler-Image ist stets ein irgendwie mystischer, ehrerbietender Akt. Es hat einen Jahrhunderte alten Schrein auf einem Fileserver und wird verehrt, und wenn es eines Morgens nicht mehr da wäre, wäre das Projekt in alle Ewigkeit verdammt, vom Glück verlassen, dem Verderben anheim gelegt.

Denn keiner weiss mehr so recht, in welcher Reihenfolge die Configuration Maps und Applications ins Image geladen werden müssen, damit ein funktionsfähiges Image dabei herauskommt. Schliesslich müssen für das GUI-Framework zunächst bestimmte Konstanten in einem Pooldictionary abgelegt sein, das Datenbank-Framework muss zunächst seine Mappings initialisiert haben, bevor die Konstanten aus der Datenbank gelesen werden können, aber eine Application des Datenbankframeworks hat als Prerequisite eine Application, die im GUI-Framework enthalten ist. Zudem kann man davon nur eine ältere Version laden, die aber gar nicht mehr aktuell ist. Bevor man die aktuelle Version dieser Application laden kann, müssen in einem Workspace drei Ausdrücke ausgeführt werden, die jemand fein säuberlich in einem Word-Dokument aufgeschrieben hat. Danach kann die aktuelle Version nachgeladen werden, und es kann dann weitergehen mit dem Laden. Zum Glück hat jemand das mit dem Workspace schon im heiligen Image gemacht und abgespeichert, sodass man glücklicherweise auf dieses Aufsetzen und einfach den aktuelleren Code nachladen kann.

Was ist denn nur falsch daran, die Arbeit der Projektahnen zu ehren und auf  ihrem Schweiß und ihrer Erfahrung aufzusetzen? Wieso sollte man sich nicht die Zeit eines kompletten Ladens aller Applications in einfrisches Image nicht sparen und auf ein vorgeladenes Image aufsetzen?

Es gibt gleich mehrere Gründe dafür, lieber heute als morgen das Messer zu wetzen und alte Zöpfe abzuschneiden.

Zum Einen ist die Gefahr groß, dass der Unterbau der Anwendung zunehmend instabil wird. Niemand kennt mehr die Zusammenhänge in der Software, und niemand kann mit Bestimmtheit sagen, was wie genau voneinander abhängt.

Nach meiner Erfahrung geht die Erscheinung des heiligen Image oft einher mit sehr seltsamen Fehlern in der Produktion, die weder nachvollziehbar, noch einfach zu beheben sind. Insbesondere dann, wenn ihr Auftreten mit einem kleinen Fehler zu tun haben, den jemand beim Abarbeiten einer 43-Punkte-Liste zum Runtime-Bau  gemacht hat.

Ein weiterer Begleitumstand des heiligen Image ist die Tatsache, dass man seit 6, 7 oder mehr Jahren auf ein und derselben Version von VisualAge Smalltalk arbeitet. Vielleicht, weil man vor einigen Jahren schon beschlossen hatte, dass das Projekt nur noch wenige Releases zu leben haben wird.

Wenn man sich zwischenzeitlich doch wieder entscheidet, auf eine neuere Version umzusteigen (etwa, weil die Integration mit anderen Anwendungen per Web Services oder allgemein XML ins Haus steht, oder weil man plant, die Anwendung auf neue Web-Füße zu stellen, und Seaside in der neuen Version 8.0 von VA Smalltalk  nutzen möchte), macht das heilige Image enorme Probleme: der komplette Unterbau der Anwendung, also fast alle mitgelieferten Basisklassen  müssen durch Neuere versionen ersetzt werden. Dabei wurden über die letzten Releases von VisualAge und VA Smalltalk Applikationen neu geordnet, Klassen verschoben, Applikationen entfernt etc.

Ein bestehendes Image etwa aus der Version 4.5 auf Version 7.5 oder gar 8.0 umzustellen, ist schwer möglich. Eine Migration auf eine neuere Version verspricht eigentlich nur Erfolg, wenn man auf ein frisches Image der neueren Version aufsetzt, und dann den eigenen Code hineinlädt. Aber das geht ja nun leider nicht so ohne weiteres, und schon gar nicht verlässlich!

Genau dabei ergeben sich zweierlei Probleme: wenn der Code durch zirkuläre Abhängigkeiten nicht geladen werden kann, stellt man die Maschine und damit ihren Nutzer vor eine unlösbare Aufgabe. Das zweite Problem ist, dass ein Ladevorgang, der zwischendurch manuelle Schritte erfordert, sehr leicht zu Fehlern führen kann.

Wenn also eine Migration auf eine neue Version von VA Smalltalk ansteht (die neue Version 8 wird mit ihrem Seaside-Support sicher ein attraktives Ziel für viele Anwender sein) , sollte man sich unbedingt Gedanken machen, ob man nicht vielleicht auch in die Gemeinschaft der Hörigen des heiligen Image gehört. Und wenn ja, wird es Zeit, sich einen Antrag auf Austritt zu besorgen.

VA Smalltalk hat mit Envy ein wirklich hervorragendes System zur Verwaltung von Code-Konfigurationen und -Abhängigkeiten, mit dem es bei geeigneter Anwendung sehr gut möglich ist, einen kompletten Ladevorgang des Projektcodes in ein leeres Image durchzuführen. Es ist, zugegebener Massen, ein Stück Arbeit, die Verflechtungen und zirkulären Abhängigkeiten zu erkennen und aufzulösen, die sich in Jahrelanger Projektpraxis aufgebaut haben. Aber es lohnt sich.

Nicht zuletzt ist eine saubere Codestruktur eine wichtige Grundlage dafür, Abläufe wie den Runtimebau (Stichworte Nightly Build und Continuous integration) oder die Erstellung eines vorgeladenen Entwicklerimages mit allen Änderungen aller Teammitglieder, z.B. immer Montags früh, zu automatisieren. Die klare Nachvollziehbarkeit und Reproduzierbarkeit dieses Ablaufes erhöht sehr schnell das Vertrauen in das Projekt und natürlich die Qualität des Enderzeugnisses.

Als allerletzte und vielleicht sogar wichtigstes Argument lässt sich ins Feld führen, dass, je länger ein Projekt mit solchen Aufräumarbeiten wartet, es sich immer tiefer in einen Sumpf aus nicht nachvollziehbaren Fehlern und Abhängigkeiten von einzelnen Personen, die in die alten Rituale noch eingeweiht sind, hineinreitet.

So wird der Runtimebauer zum Hohepriester und unnahbaren Übermenschen. Aber auch zum Sklaven seiner eigenen Macht: denn er kann sich in der Zeit, die er in die Zeremonie der alten Rituale investiert, nicht produktiv an der Weiterentwicklung des Projektes beteiligen, was ihn womöglich frustriert und demotiviert…

Die Gute Nachricht hierzu ist: es gibt Hilfe!

Auf dem VA Smalltalk Forum 2007 habe ich einen Vortrag zum Thema Migration von VA Smalltalk – Projekten nach Version 7.x gehalten, der gerade der Library-Hygiene einen weiten Raum gibt.  In der Vergangenheit habe ich bereits mehreren Kunden bei der Migration von älteren VA Smalltalk – Versionen geholfen und dabei fast immer auch das Thema der Ladbarkeit von Code beackern müssen. Auch die Automatisierung von Ladevorgängen (Streamkonzept) und Runtimebau sowie ein geeignetes Konfigurationsmanegement war dabei häufig ein Thema. Wenn also das Thema Migration und Automatisierung in Ihrem VA Smalltalk – Projekt ein Thema sind, sollten wir uns unbedingt mal unterhalten.

Zum Abschluss hätte ich noch einen Lesetipp für alle, die sich mit dem Code-Management in VA Smalltalk und Envy näher beschäftigen möchten. Eine Pflichtlektüre für jeden Runtimebauer, Build Manager oder Packager oder wie auch immer die Rolle im Projekt heissen mag.