| Nach Karl Valentin |
| Er: |
Wos is na des im Kucha drinna?
San des Fliagn? |
| Sie: |
Naa, des san doch koa Fliagn.
Des san Sultaninen. |
| Er: |
Woos? Sultaninen?
Da san mir ja Fliagn no liaba. |
|
Kochen ist eine Kunst, und Rezepte erleichtern die Arbeit, diese Kunst zu
erlernen. Wie in der Küche, so gibt es auch in der Informatik Zutaten,
Gewürze und Kräuter, die besser nicht gemeinsam verwendet werden
sollten und kulinarische Entgleisungen hervorbringen, die
gelegentlich nicht einmal dem Koch schmecken (ich denke da an so
naheliegende Dinge wie "Erdbeeren in Knoblauchsoße auf roher Seehundhaut")
Ein paar praxiserprobte Rezepte und Vorgehensweisen sollen deshalb nicht
fehlen:
Das Flußdiagramm erfreut sich in vielen Bereichen der Datenverarbeitung
immer noch großer Verbreitung. Insbesondere bei Nicht-Informatikern
ist diese Art der Aufschreibung einer Befehlsfolge sehr bekannt und zum Teil
auch beliebt, bietet sie doch einen deutlichen Blick auf die Abläufe
im Programm oder in einer Funktion. Wirklich? Ich gebe hier das klassische
Rezept für „Spaghetti computese".
-
Man nehme: eine Aufgabe, die programmtechnisch zu lösen ist, Bleistift,
Radiergummi und eine ausreichende Menge Schreibpapier.
-
Ein erster Blick zeigt, daß die Lösung der Aufgabe aus einer Eingabe,
ein paar Verarbeitungsschritten und einer Ausgabe besteht. Die ersten
Kästchen werden gezeichnet.
-
Während des Zeichnens des dritten Kästchens (=zweiten
Verarbeitungsschrittes) fällt beim Entwerfen des Flußdiagramms
auf, daß manche Eingaben besser nicht verarbeitet werden sollten, da
sie von vornherein fehlerhaft sind. Es wird folglich eine Raute zwische Eingabe
und ersten Verarbeitungsschritt gemalt. Prüfen der Eingabe, Verzweigung
im Fehlerfall mittels Rückwärtspfeil zur Eingabe.
-
Endlich wieder zu den Verabeitungsschritten zurückgekehrt, stellt sich
heraus, daß der dritte Verarbeitungsschritt in 10 Durchgängen
gleicher Bauart erfolgen muß. Flugs wird die Vereinbarung einer Variablen
namens i vorgenommen. Eine weitere Raute prüft, ob i schon einen bestimmten
Wert erreicht hat, in diesem Falle 10. Wenn ja, dann geht es weiter zu Ausgabe,
wenn nein, dann muß nochmal der Schritt 3 durchlaufen werden.
-
Oha! Eigentlich sollte i in jedem der Schritte auch um 1 erhöht werden.
Schnell noch ein Kistchen vor die Raute.
-
Auf dem Zeichenblatt wird’s langsam eng. Besser jetzt alles in der Mitte
aufteilen, auf zwei Blättern je einen halben Ablauf neu zeichnen und
mittels vier numerierten Verbindungskringeln („Konnektoren") logisch
aneinanderfügen.
-
Gedankenblitz! Die Variable i sollte vorsorglich mit 1 belegt werden. Also
noch eine Schachtel hineinquetschen. Unversehens gerät diese Box an
die Stelle zwischen dem Rücksprung und der Prüfung.
-
Manche der berechneten Ergebnisse sind im Sinne der Aufgabenstellung nicht
brauchbar; besser ist es, auch eine Prüfung der Ausgabe vorzunehmen
und ggf. einen Fehler zu melden. Raute und zwei Pfeile. Bei Fehlern sollte
dem Anwender des Programms die Chance gegeben werden, noch einmal den Ablauf
zu benutzen. Also Linie nach oben, neuer Konnektor - und weiter auf dem vorigen
Blatt. Verbindung zum ersten Verarbeitungsschritt.
-
Das Kästchen mit dem Zuweisen des Wertes 1 an die Variable i wirkt irgendwie
deplaziert. Warum eigentlich wird i mit 1 belegt, wenn sie danach ohnehin
um 1 erhöht wird? Besser, wir fassen das zusammen und machen eine Anweisung
daraus, die i gleich den Wert 2 zuweist.
-
Eigentlich wäre es ja sinnvoll, dem Anwender nicht zu zwingen, den Ablauf
nochmal zu nutzen, vielleicht sollte ja vorher gefragt werden, ob’s
nochmal gewünscht ist. Also schleunigst auf Blatt 2 eine Ausgabe machen,
die Antwort einlesen und danach mit einer weiteren Verzweigung entscheiden,
ob, oder ob nicht. Ein Pfeil nach unten, einer nach oben und der nächste
Konnektor ist fällig. Erstes Blatt, vor die Eingabe.
-
Moment mal, hätte das vorhin nicht auch im Fehlerfall sinnvoll stattfinden
sollen? Nur welcher Konnektor war dafür zuständig?
-
Wozu diente i denn gleich wieder? Achso ja, 10 Schleifendurchläufe.
Hmm, 10-2 = 8. Besser, der Endewert wird auf 12 erhöht, denn 12-2 =10.
-
Vor die Eingabe sollte höflicherweise eine Ausgabe gesetzt werden, die
den Anwender des Programms freundlich um eine Eingabe bittet. Dasselbe sollte
auch bei fehlerhaften Eingaben geschehen. (Noch ein letzter Schritt... Ich
bestreite, daß ich unter Triakaidekaphobie leide!)
-
Das mit den 12-2=10 kann doch nicht stimmen! Beim Schleifenende wird erst
nach der Verarbeitung geprüft. Die Schleife läuft also einmal zu
oft. Der Wert 12 wird durch 11 ersetzt.
Das ist das Basisrezept für „Spaghetti computese". Zur Erinnerung:
es sollte nur die einfache Verarbeitung einer Eingabe und ein, zwei elementare
Fehlerprüfungen stattfinden.
Das Flußdiagramm gibt sehr genau die stolpernde Evolution der
Gedankengänge des Programmkochs wieder, stellt aber weder ein Mittel
zur Unterstützung eines strukturierten Gedankenflusses dar, noch
schützt es vor wildesten Fehlern.Vielleicht erahnen Sie, warum ich seit
über zwanzig Jahren eine tiefverwurzelte Abneigung gegen Flußdiagramme
habe.
P.S. Haben Sie’s gemerkt? Die Schleife aus dem Rezept ist eine
Endlosschleife.
Goldene Regeln für den
Softwareentwurf
Nichts ist einfacher, als Software zu entwickeln. Aber selbst bei solch banalen
Arbeiten treten gelegentlich Fehler auf oder Neulinge fühlen sich grundlos
unsicher. Die "Goldenen Regeln" sollen hier eine helfende Hand reichen.
-
Verwenden Sie Arrays zum Speichern von Daten, egal welcher Art! Nur blutige
Anfänger benutzen Typkonzepte und die sogenannten „strukturierten"
Datentypen. Objektorientierte Programmierung und andere dubiose Moderscheinungen
aus dem akademischen Umfeld sollten Sie links liegen lassen!
-
Programmieren Sie Basisfunktionen und Teilabläufe, bevor Sie
mit der Spezifikation beginnen! Wenn die meisten Funktionen schon bekannt
sind, gibt es das einen schönen Baukasten, aus dem Sie dann schöpfen
können. Schließlich muß der Erfolg der LEGO-Steine irgendwo
herkommen.
-
Machen Sie Ihren Kunden, Auftraggebern und sich selbst klar, daß jedes
Programm viel Speicher braucht, sehr langsam ist und einen schnelleren Rechner
benötigt.
-
Machen Sie Fehler! Jedes Programm, das gut ist, muß eine Anzahl Fehler
enthalten. Wie anders könnten Sie die Benutzer des Programms davon
überzeugen, daß Sie hier eine schwierige Aufgabe lösen
mußten? Abgesehen davon, wäre es doch schade, wenn Sie nicht nur
die Erwartungshaltung der User enttäuschten, sondern sich
darüberhinaus auch noch den Weg in die Zukunft verbauen. Kein Mensch
kauft die Nachfolgeversion Ihrer Software, wenn keine Fehler zu beheben sind.
Was Billy Gates kann, können Sie schon lange!
-
Verwenden Sie Flußdiagramme! Die sehen beeindruckend aus und zeigen
jedem Auftraggeber, daß Sie das Thema im Detail durchdrungen haben.
-
Lassen Sie Ihre Software organisch wachsen! Nutzen Sie jede Chance, Abläufe
vielfältig verzweigen zu lassen und Ihre User mit immer neuen Features
zu beglücken. Gute Software zeichnet sich durch stetige Jahresringe
aus, die den Stamm des "Baumes" dicker werden lassen. Jeder bewundert
tausendjährige knorrige Eichen, keiner den Weihnachtsbaum vom letzten
Jahr.
-
Datensicherung und Versionsverwaltung sind Dinge, die dem wahren Entwickler
nicht gut zu Gesicht stehen. Profis beherrschen ihre Software! Wenn
wirklich mal was schiefgeht, ist die Sache eh' gleich neu programmiert.
-
Verzichten Sie auf Kommentare! Nur Warmduscher schreiben Kommentare. Wer
kommentiert, weiß sowieso nicht, wie sein Programm funktioniert. Kommentare
sind Zeitverschwendung. Der Auftraggeber zahlt für Code, aber nicht
für Romane!
-
Verweigern Sie den Gehorsam, falls Ihnen Programmierrichtlinien aufgedrückt
werden sollen! Programmierrichtlinien behindern die Kreativität und
stellen unnütze Einschränkungen dar - Im Vertrauen gefragt: Wer
hält sich schon an Programmierrichtlinien? (Eben! Sag’ ich
doch!)
-
Wirkliche Könner benutzen zur Ablaufsteuerung in weit entfernten Funktionen
globale Variablen. Globale Variablen sind das A und O raffinierter
Programmierung. Selbst wenn mal was nicht läuft, wie Sie wollten, gehen
Sie der Sache nach! Mit großer Wahrscheinlichkeit haben Sie einen neuen
Algorithmus gefunden. Macht nichts, wenn keiner weiß, wofür er
gut ist. Aber wenn Sie die Lösung haben, läßt sich ein geeignetes
Problem sicher finden. Vielleicht läßt sich sogar Ihre
ursprüngliche Aufgabenstellung passend modifizieren? Die Chancen stehen
gut, daß dann der Algorithmus nach Ihnen benannt wird und Sie berühmt
werden.
Ausnahmsweise ernst gemeint: Es gibt wenige Dinge in unserem Fachgebiet,
die mir spontan die Galle übergehen lassen. Hier die idiotischsten
Bemerkungen:
-
"Wieso Softwarebeschreibung? Du hast doch den Quellcode!" Der Quellcode
ist schlicht gesagt keinen Schuß Pulver wert, wenn dahinter keine saubere
Software-Architektur und ein gutes Design stehen. Der Quellcode ist sogar
weniger wert als ein Flußdiagramm, denn das täuscht wenigstens
noch etwas Logik vor, doch der Code ohne Dokumentation ist ein geistiges
Armutszeugnis - besonders für jene, die ihn für einen
Spezifikationsersatz halten.
-
"Wenn die Schleife nicht richtig zählt, dann erhöhen/erniedrigen
wir den Wert der Ende-Bedingung." Schluß! Stecker raus! Wer so
argumentiert, hat von den elementarsten Dingen der Programmierung keinen
Dunst. So eine Äußerung sollte Anlaß für eine fristlose
Kündigung sein.
-
"Kaufen Sie halt einen schnelleren Rechner!" Nein. Ich suche mir einen
besseren Softwareentwickler. Wer so redet, hat das Wesen der Algorithmik
nicht verstanden. Nicht jedes Vorbild, selbst wenn es gewisse wirtschaftlich
erfolgreiche Unternehmen sein mögen, rechtfertigt die Übertragung
derer Beschränktheit auf die eigenen Programme.
-
"Software-Architektur? Ja, das ist Java!" Quatsch! Java ist keine
Architektur, sondern eine Programmiersprache wie andere auch. Selbst ein
reichhaltiger Fundus an Bibliotheken ist kein Ersatz für die Gestaltung
einer sauberen Software-Architektur. Wer so redet, sollte sich sein Lehrgeld
an der Werkskasse auszahlen lassen und schleunigst das Weite suchen, umsatteln
und Kartoffeln pflanzen. Die werden ganz sicher dick.