rc1 Pattern – Optmist vs. Pessimist

Ein optimistisch veranlagter Softwareentwickler (es soll so was anscheinend auch geben) geht von dem goodwill-case aus und implementiert zum Beispiel ein statusbehafteter Prozess mit dem erfolgreichem Status als initialen Wert. Bsp:

class MyProcess {
    state OK;
    ...
}

Ich glaube zu meinen, dass er sich dabei folgendes denkt: Ich spare mir das im 99,99% der Fällen notwendiges explizites Setzen diesen Zustandes in dem ich es einfach damit initiere. Falls der Zustand anders gesetzt werden soll - kein Problem, dann mache ich es eben. – so weit, so gut.

Doch dann, eines schönen Tages (der Optimist ist schon längst weitergezogen) beschäftigen sich ein paar Datenanalysten mit einigen Anomalien – mehrere Wochen lang. Ein paar Monate später vermutet man doch ein Fehler in der Implementierung – so wird ein Analyse Ticket eröffnet mit dem Hinweis dass da wohl was an der Transaktionalität der Anwendung falsch sein müsste. Diese behauptet, dass der Prozess erfolgreich verarbeitet wurde, die Datenanalyse jedoch eindeutig beweist dass dies nicht immer der Fall ist.

Die mehrtägige Codeanalyse entblößt endlich das Märchen bei dem ein unerwarteter Ereignis die Verarbeitung stoppte und dabei nicht implizit den Status der Verarbeitung auf Fehler setzte. Es steht fest, der 99,99% Ersparnis des Optimisten hat Kosten in dem höheren vierstelligen Bereich verursacht.

Die Meisten würden sich fragen wieso er wohl so vorgegangen ist, es ist doch klar dass man dabei im oben beschriebenes Szenario landet.

Weil es eben doch nicht für alle klar ist, beschriebe ich hiermit das Best Practise dass man eigentlich den Zustand erst nach dem letzten Commit auf erfolgreich setzen darf. Niemals vorher. Vorher muss klar ersichtlich sein dass der Status nicht initiert wurde. Wenn man dabei jeden Schritt erzwingen möchte, dass es diesen Zustand aktualisiert, so kann man den Status am Anfang mit dem Fehler initiieren. Ein rigoroses Vorgehen ich weiß, letztendlich aber sehr sparsam – in großen Projekten. Optimal soll der Zustand als nicht gesetzt/“NOT_SET“ klar gekennzeichnet werden.

class MyProcess {
    state NOT_SET;
    ...
}

Sollte dieser Zustand am Ende der Verarbeitung immer noch nicht überschrieben worden sein, dann sollte die Verarbeitung wie mit einem unerwarteten Zustand fehlerhaft abgeschlossen werden.

Im Linux Skripten initiert man an dem Skript Anfang eine return code (rc) Variable mit dem Wert 1 das für den Fehler steht. Das Skript wird mit exit rc beendet. Dazwischen findet die Verarbeitung statt und bei einer Erfolgreichen Verarbeitung wird die Variable auf 0 gesetzt. Damit ist es sichergestellt dass in dem Fall – und nur dann – mit einem OK die Verarbeitung quitttiert wird.

rc = 1 #initiate return code with error
...
do this
change that
commit something else
rc = 0 #set to success
...
exit rc #exit with return code

Daher finde ich rc1 als ein Name dem man sich für dieses Verhalten sehr einfach einprägen kann und hoffe, dass auch ein Optimist dies einsehen kann.

Vielen Dank für Deine Zeit und liebe Grüße,
Azmir Abdi

PS: Ich würde mich über einen Kommentar oder eine Email sehr freuen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.