Praxis Dr. Inselfisch

Psychologie, Philosophie und Programmierung

Der Else-Zweig: es gibt immer eine Alternative

| Keine Kommentare

Das erste Kon­strukt, das man gemein­hin in ein­er Pro­gram­mier­sprache lernt, ist meis­tens ein If, auf Deutsch ein Wenn. Wenn a gröss­er als b ist, mach etwas, das ist die Aus­gangs­ba­sis für viele Anfänger­pro­gramme. Dabei lernt man meis­tens auch ziem­lich schnell, dass die If-Bedin­gung sel­ten ein-ein­deutig ist, man muss immer noch ein paar Alter­na­tiv­en berück­sichti­gen. Was ist zum Beispiel, wenn a nicht gröss­er als b ist, son­dern klein­er? Was macht man dann? Und was ist, wenn die bei­den Werte gle­ich sind? Dafür gibt es die Else-Bedin­gung, also die Alter­na­tive, was passieren soll wenn die If-Bedin­gung nicht zutrifft.

Das kriegt man in ver­schärfter Form immer wieder um die Ohren, beson­ders wenn es um Benutzereingaben geht. Nehmen wir mal an, wir bit­ten den Benutzer um die Eingabe ein­er Zahl:

eingabe_screenshot

eingabe_screenshot

Das sieht sehr straight­for­ward aus, hat es aber ganz schön in sich. Als Pro­gram­mier­er ist man näm­lich häu­fig damit beschäftigt, Benutzereingaben “wasserdicht” zu machen, das heißt, man muss alle möglichen Kon­stel­la­tio­nen berück­sichti­gen und vorauss­chauend bedenken, was der Benutzer denn in unserem kleinen Eingabefor­mu­lar alles machen kön­nte. Im besten Fall gibt er eine Zahl ein und klickt auf “Abschick­en”, das ist Fall eins und leicht zu behan­deln. Was aber passiert, wenn er keine Zahl, son­dern einen Buch­staben oder son­stige Zeichen ein­gibt? Und was passiert, wenn er gar nichts ein­gibt und trotz­dem auf Abschick­en klickt? Und was passiert, wenn er nicht auf Abschick­en klickt? Dann passiert näm­lich gar nichts…

Sie sehen schon, das kann beliebig kom­plex wer­den. Deswe­gen muss ein guter Pro­gram­mier­er immer für den größten AU mit­denken (AU= Insid­er­witz, Ahnungslos­es­ter User) und alle Even­tu­al­itäten berück­sichti­gen. Das übt — auch fürs richtige Leben.

Wenn ein guter Pro­gram­mier­er über ein Prob­lem nach­denkt, berück­sichtigt er immer auch den Else-Zweig, auch wenn der auf den ersten Blick nicht so offen­sichtlich erscheint. Wir sind es gewohnt, die Aus­gangs­ba­sis sehr genau anzuschauen, und alle möglichen Vari­anten der Vorge­hensweise durchzus­pie­len. Ein richtig guter Pro­gram­mier­er wird dafür sor­gen, dass der Benutzer gar keine Fehleingaben machen kann, dass beispiel­sweise eine aus­sagekräftige Fehler­mel­dung kommt wenn der User Buch­staben eingegeben hat, und das Pro­gramm zum Aus­gangspunkt zurück­kehrt ohne dass etwas passiert:

fehlermeldung

fehler­mel­dung

Deswe­gen sind gute Pro­gram­mier­er auch immer gute Prob­lem-Ana­lytik­er, sie sind es gewohnt mit allen Even­tu­al­itäten zu rech­nen und ihre Pro­gramm so zu gestal­ten, dass jed­er nur denkbare Fehler abge­fan­gen wird.

In Com­put­er­pro­gram­men geht das meis­tens — meis­tens, aber nicht immer. Je kom­plex­er die Aus­gangssi­t­u­a­tion, desto schwieriger wird es, alle möglichen Ereignisse vorauszuse­hen und entsprechend zu behan­deln. Schließlich sind wir keine Hellse­her, und deswe­gen ste­ht am Ende ein­er pro­fes­sionellen Pro­gram­men­twick­lung auch immer ein aus­giebiger Test, auf neudeutsch Usabil­i­ty Test. In dem dür­fen und sollen die Anwen­der, also die Per­so­n­en, die das Pro­gramm let­z­tendlich benutzen sollen, das Pro­gramm so bedi­enen wie es ihnen ger­ade ein­fällt, und auch mal richti­gen Käse und Unsinn eingeben und bewußt Fehlbe­di­enun­gen provozieren. Ein richtig gutes Pro­gramm kann sowas ab ohne abzustürzen, und wenns während des Tests irgend­wo kracht, muss der Pro­gram­mier­er nochmal ran und eine Fehler­be­hand­lung für diesen speziellen Fall ein­bauen. Im Nor­mal­fall braucht man sog­ar mehrere Testrun­den, um die Pro­gramme auch bei krass­er Fehlbe­di­enung absturzfrei zu machen, erst dann entste­ht Usabil­i­ty oder Benutzer­fre­undlichkeit.

Das heisst auch, dass ein guter Pro­gram­mier­er Nachko­r­rek­turen nicht als lästiges Übel, son­dern als notwendi­gen Bestandteil sein­er Arbeit sieht, schließlich ist auch der beste Pro­gram­mier­er nicht unfehlbar, und kein auch nur etwas kom­plex­eres Pro­gramm wird im ersten Anlauf schon fehler­frei laufen.

Das übt fürs richtige Leben: am Anfang ste­ht die Auf­gaben­stel­lung (das Pro­gramm, oder auch das Prob­lem). Dann über­legt man sich alle möglichen Lösun­gen und sucht die aus, die einem am erfol­gver­sprechend­sten erscheint. Falls die dann doch die Auf­gabe oder das Prob­lem nicht hun­dert­prozentig löst, kom­men die Nachko­r­rek­tu­rar­beit­en, und man pro­bierts auf eine andere Art und Weise noch ein­mal. Dies nen­nt man einen iter­a­tiv­en Ansatz, und wenn man die Tests und die Nachko­r­rek­turen richtig ange­ht, kommt man meist recht schnell zu ein­er zufrieden­stel­len­den Lösung.

Wir sind näm­lich nicht unfehlbar, aber wir sind lern­fähig — und das ist im richti­gen Leben auf jeden Fall eine sehr nüt­zliche Fähigkeit, meinen sie nicht auch?

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.