And it burns burns burns ... voll auf der Arbeit!

Vorwort

Dies ist ein langer Beitrag, der von technischen Begriffen nur so strotzt und ganz im Stil von Informatikern absichtlich ohne Bilder verfasst wurde. Wen der ganze Hintergrund nicht interessiert, der darf gerne nach unten scrollen und ab "Die Attacke" lesen oder es ganz bleiben lassen.

Vorgeschichte:

Ok, hierfür muss ich mal etwas länger ausholen und so grob erzählen was genau ich eigentlich bei Siemens mache: Da ich im TestAutomation Team bin ist unser Fokus wie der Name schon sagt die Automatisierung von Tests. Fast man diesen Begriff etwas weiter auf, dann kann man sagen, dass wir das Testen einfacher machen sollen. Mein Beitrag dabei ist die Arbeit an einem Tool namens SkyView, das aus Datenbanken zweier Programme, die zum einen Tests ausführen (TestDirector) oder Fehler verwalten (CharmNT), Daten ausliest und graphisch und tabellarisch aufarbeitet.

Kurz gesagt ich habe Daten und mache daraus viele Tabellen und Diagramme. Durch das Ergebnis kann man nun z.B. sehen wie viele Testfälle gut gelaufen sind, wo es Fehler gab, wie viele Testschritte in einem Test ausgeführt wurden, usw.

Was die Berechnung der Ergebnisse angeht wird diese, neben den ausgewählten Tests, im Wesentlichen von zwei Dingen beeinflusst.
So kann man zwischen einer statischen Ansicht, in der nur bestimmte Stati eines Tests ausgegeben werden, und einer dynamischen Ansicht wählen, bei der alle verfügbaren Stati dargestellt werden.
Die zweite Sache ist, dass es bei jeder Software ja verschiedene Versionen gibt (genannt Builds). Man kann hier nun entweder mehrere verschiedene Builds auswählen oder keinen bestimmten.
Im Prinzip ist es ziemlich egal, was die einzelnen Begriffe bedeuten. Fakt ist nur, dass die Skripten zur Generierung der Reports jeweils aus vier Teilen bestanden: mit verschiedenen Builds/ohne Builds, jeweils unterteilt in dynamisch/statisch.

Mein Job:

So, das war also die Ausgangslage. Das Problem an der ganzen Sache war, dass diese vier Teile im Prinzip alle genau das Gleiche machten. Kam nun eine neue Anforderung für SkyView oder sollte ein Fehler behoben werden musste man diesen in allen vier Teilen ändern, bzw erstmal herausfinden welcher der vier Teile falsch war. Hinzu kam, dass es sich nicht nur um ein Skript sondern um sieben handelte. So gab es Funktionen die in allen sieben Skripten an jeweils vier Stellen, also 28x vorkamen aber alle das selbe machten.
Leider war das Layout der Reports dazu alles andere als einheitlich, was bei so vielen gleichen aber doch verschiedenen Teilen auch kaum verwunderlich ist.

Langer Rede kurzer Sinn, ich bin, als ich dieses Chaos gesehen habe, erst mal zu meinem Chef gegangen und habe gesagt, bevor ich an neuen Features arbeite, will ich aufräumen, gib mir ne Woche Zeit! Und die gab er mir auch, mit dem Ergebnis: Ich habe aus 9800 Codezeilen 4500 gemacht, neue Request können um einiges schneller eingebaut werden, das Layout ist überall einheitlich, und und und.

Die Architektur:

Ok, langsam wirds lustig. Natürlich habe ich diese ganzen Änderungen nicht auf dem Livesystem (Production-Server) vorgenommen auf dem die Manager ihre Reports abrufen, sondern auf einem Entwicklungssystem (Development-Server). Das normale Vorgehen ist so: Ein neuer Request wird eingebaut, die betroffenen Leute schaun sich das auf dem Development-Server an und wenn alles passt wirds auf den Production-Server geschoben.

Der Auslöser:

Bis Montag ging im Prinzip alles wunderbar, ich hab auf meinem Development System rumgespielt und die Manager auf dem Production. Am Montag allerdings wurde eines der Programme aus dem die Daten ausgelesen werden (der TestDirector) upgedated, weswegen ich die Verbindungsdaten aktualisieren musste. Dies tat ich auf dem Development-Server und schrieb eine mail an alle dies doch bitte zu überprüfen.

Die Attacke:

Kurz darauf prasselten zich mails auf mich ein, was denn dieses komische Layout soll (gemeint war glaub ich, dieses komische überall einheitliche Layout ;)), die Werte stimmen ja überhaupt nicht mehr (zugegeben, an einer Stelle wurden Werte noch falsch berechnet, was allerdings auf dem Production-Server auch der Fall war) und überhaupt die Reihenfolge der Spalten stimmt ganz und gar nicht (im Zuge der Restrukturierung wurden Teile zusammengefasst, die vorher 28x vorkamen und jetzt nur noch einmal, dadurch wurde eine Spalte die vorher an dritter Stelle war an fünfte gestellt, ganz anders also).
Hinzu kam, dass ich am Dienstag noch die Ordner auf dem Server reorganisierte und dabei 8000 nicht mehr verwendete Files löschen konnte und die Struktur weiter deutlich vereinfachte, dabei aber die Links zum Aufrufen der Skripts ein klein wenig anders aussahen. An Stelle von SkyView/TD jetzt SkyView-TD.
Es gab also viiiiieeeeel Feedback mit Sätzen wie "bevor man nicht verlangte Restrukturierungen macht solle man sich doch lieber um offene Request kümmern" (Frage: Baut man einen Wolkenkratzer in einen Sumpf? Nein, man legt ihn erst trocken und bereitet ihn vor!).
Das Schöne war, dass dummerweise die alten Skripte mit dem neuen TestDirector nicht mehr liefen, da sie viel zu langsam waren und die Datenbank ständig einen Timeout brachte. Zufälligerweise hab ich im Zuge der Restrukturierung auch die Datenbankabfragen geringfügig optimiert, so dass Anfragen, die vorher 360 Sekunden dauerten in 0.2 Sekunden ausgeführt wurden.
Als ich den Anwendern diese kleine Detail mitteilte wurde es plötzlich still in meinem Postfach und einen Tag später tröpfelten die ersten Mails ein, wann denn die neuen Skripten auf den Production-Server kommen ... :) Außerdem kamen ein paar Kollegen auch zu mir oder meinem Chef und entschuldigten sich so halb, für eventuelle Überreaktionen. Nun, natürlich nicht direkt, aber es wurde eben angedeutet oder herumgedruckst

Fazit:

Durch diese ganze Geschichte hab ich jetzt jedenfalls endlich mal mitbekommen, wie es ist, wenn Leute ein bisschen ausflippen und erstmal einen Schuldigen suchen bevor sie mal nachdenken oder einfach nachfragen. Ich bin während der ganzen Zeit doch recht ruhig geblieben, denn ich wusste, dass meine Arbeit absolut notwendig und letztendlich auch unumgänglich war.
Das Beste an der Geschichte war aber auf jeden Fall mein Chef, der mich bei der ganzen Sache 100%ig unterstützte und in einem Mail an mich (frei übersetzt) schrieb: "Lach einfach drüber. Nimms locker! Wenn dich Leute wegen irgendwas anmachen, schick sie einfach zu mir, ich kümmer mich darum."

Disclaimer:

Ich möchte hier weder meine Vorgänger noch ihre Arbeit an SkyView schlecht machen. Es ist nunmal in der Entwicklung so, dass ständig neue Anfragen kommen etwas in ein System einzubaun und dass kaum Zeit für Dokumentationen oder Aufräumarbeiten bleibt. Ich hatte einfach nur das Glück mich durchsetzen zu können, dass diese Zeit zur Restrukturierung absolut notwendig ist.