Das erste Konstrukt, das man gemeinhin in einer Programmiersprache lernt, ist meistens ein If, auf Deutsch ein Wenn. Wenn a grösser als b ist, mach etwas, das ist die Ausgangsbasis für viele Anfängerprogramme. Dabei lernt man meistens auch ziemlich schnell, dass die If-Bedingung selten ein-eindeutig ist, man muss immer noch ein paar Alternativen berücksichtigen. Was ist zum Beispiel, wenn a nicht grösser als b ist, sondern kleiner? Was macht man dann? Und was ist, wenn die beiden Werte gleich sind? Dafür gibt es die Else-Bedingung, also die Alternative, was passieren soll wenn die If-Bedingung nicht zutrifft.
Das kriegt man in verschärfter Form immer wieder um die Ohren, besonders wenn es um Benutzereingaben geht. Nehmen wir mal an, wir bitten den Benutzer um die Eingabe einer Zahl:
eingabe_screenshot
Das sieht sehr straightforward aus, hat es aber ganz schön in sich. Als Programmierer ist man nämlich häufig damit beschäftigt, Benutzereingaben “wasserdicht” zu machen, das heißt, man muss alle möglichen Konstellationen berücksichtigen und vorausschauend bedenken, was der Benutzer denn in unserem kleinen Eingabeformular alles machen könnte. Im besten Fall gibt er eine Zahl ein und klickt auf “Abschicken”, das ist Fall eins und leicht zu behandeln. Was aber passiert, wenn er keine Zahl, sondern einen Buchstaben oder sonstige Zeichen eingibt? Und was passiert, wenn er gar nichts eingibt und trotzdem auf Abschicken klickt? Und was passiert, wenn er nicht auf Abschicken klickt? Dann passiert nämlich gar nichts…
Sie sehen schon, das kann beliebig komplex werden. Deswegen muss ein guter Programmierer immer für den größten AU mitdenken (AU= Insiderwitz, Ahnungslosester User) und alle Eventualitäten berücksichtigen. Das übt — auch fürs richtige Leben.
Wenn ein guter Programmierer über ein Problem nachdenkt, berücksichtigt er immer auch den Else-Zweig, auch wenn der auf den ersten Blick nicht so offensichtlich erscheint. Wir sind es gewohnt, die Ausgangsbasis sehr genau anzuschauen, und alle möglichen Varianten der Vorgehensweise durchzuspielen. Ein richtig guter Programmierer wird dafür sorgen, dass der Benutzer gar keine Fehleingaben machen kann, dass beispielsweise eine aussagekräftige Fehlermeldung kommt wenn der User Buchstaben eingegeben hat, und das Programm zum Ausgangspunkt zurückkehrt ohne dass etwas passiert:
fehlermeldung
Deswegen sind gute Programmierer auch immer gute Problem-Analytiker, sie sind es gewohnt mit allen Eventualitäten zu rechnen und ihre Programm so zu gestalten, dass jeder nur denkbare Fehler abgefangen wird.
In Computerprogrammen geht das meistens — meistens, aber nicht immer. Je komplexer die Ausgangssituation, desto schwieriger wird es, alle möglichen Ereignisse vorauszusehen und entsprechend zu behandeln. Schließlich sind wir keine Hellseher, und deswegen steht am Ende einer professionellen Programmentwicklung auch immer ein ausgiebiger Test, auf neudeutsch Usability Test. In dem dürfen und sollen die Anwender, also die Personen, die das Programm letztendlich benutzen sollen, das Programm so bedienen wie es ihnen gerade einfällt, und auch mal richtigen Käse und Unsinn eingeben und bewußt Fehlbedienungen provozieren. Ein richtig gutes Programm kann sowas ab ohne abzustürzen, und wenns während des Tests irgendwo kracht, muss der Programmierer nochmal ran und eine Fehlerbehandlung für diesen speziellen Fall einbauen. Im Normalfall braucht man sogar mehrere Testrunden, um die Programme auch bei krasser Fehlbedienung absturzfrei zu machen, erst dann entsteht Usability oder Benutzerfreundlichkeit.
Das heisst auch, dass ein guter Programmierer Nachkorrekturen nicht als lästiges Übel, sondern als notwendigen Bestandteil seiner Arbeit sieht, schließlich ist auch der beste Programmierer nicht unfehlbar, und kein auch nur etwas komplexeres Programm wird im ersten Anlauf schon fehlerfrei laufen.
Das übt fürs richtige Leben: am Anfang steht die Aufgabenstellung (das Programm, oder auch das Problem). Dann überlegt man sich alle möglichen Lösungen und sucht die aus, die einem am erfolgversprechendsten erscheint. Falls die dann doch die Aufgabe oder das Problem nicht hundertprozentig löst, kommen die Nachkorrekturarbeiten, und man probierts auf eine andere Art und Weise noch einmal. Dies nennt man einen iterativen Ansatz, und wenn man die Tests und die Nachkorrekturen richtig angeht, kommt man meist recht schnell zu einer zufriedenstellenden Lösung.
Wir sind nämlich nicht unfehlbar, aber wir sind lernfähig — und das ist im richtigen Leben auf jeden Fall eine sehr nützliche Fähigkeit, meinen sie nicht auch?