|
| |||||||||||||||||||||||||||||||||||||
› Pferdemarkt
› Anzeigenmarkt
› Messe
neu: jetzt auch unter
EquiVoX.de
›RSS
› Menü
› Hilfe-FAQ
› Login
› Newsletter
› Bücher
› Notizen
› Presse
› Termine
› Leserbrief
› Heute neu
Bildmaterial 
Informationen
|
 › voriges Editorial |  › Ãœbersicht Editorials |  › nächstes Editorial |  › Ausgabe 639 |
| Editorial zu Ausgabe 639 | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Test Eine der ersten Lektionen, die ich bei der Erstellung von Internetseiten gelernt habe, ist die wunderbare Eigenschaft des Webservers, bei Fehlern Rückmeldungen erstatten zu können. Das ist wichtig, denn beim Programmieren kann man nicht alle Eventualitäten übersehen. Man mag noch so einfach anfangen, kompliziert wird die Sache von ganz alleine. Daher ist es wichtig, überall Mechanismen einzubauen, die auf Fehler aufmerksam machen können. Auch das ist etwas, was ein Programmierer sehr früh gelernt: Man macht ständig Annahmen, und oft macht man sich nicht klar, dass diese Annahmen unter Umständen gar nicht erfüllt sind. Man muss also im Grunde ständig überprüfen, ob man überhaupt Annahmen macht und ob diese erfüllt sind. Ein Beispiel: Heute habe ich eine gute Stunde damit zugebracht, einen Fehler aufzuklären, der durch eine Suchmaschine aufgedeckt wurde. Dieser Fehler wurde von meinem Programm nicht nur entdeckt, sondern es wurde auch eine E-Mail generiert, die mich über die näheren Umstände informierte. Er stellte sich heraus, dass die Suchmaschine einen Link anforderte, der eine Übersicht im Pferdemarkt über eine bestimmte Rasse geben sollte. Eine solche Anfrage sollte natürlich keinen Fehler auslösen. Was war passiert? Der Name der Rasse war Bestandteil der Internetadresse, und da dieser außerdem als Label des Links fungierte, also als sichtbarer Text für den Benutzer, ergab sich hier ein Designproblem. Der Name war einfach viel zu lang, als dass dies gut aussehen konnte: Deutsch Partbred Shetland-Mini (DPbSh-Mini). Wegen dieses Schönheitsproblems hatte ich das Label, also den Text des Links, den man sieht, verkürzt. Dummerweise hatte ich das so realisiert, dass aus dem Label die Webadresse generiert wird, und damit war der Rassename jetzt verkürzt. Da ich aber diese Anfrage wiederum nach dem Rassenamen auflöste, konnte die Rasse nicht gefunden werden. Das war der Fehler. Debugging Programmieren ist wunderbar - solange man damit beschäftigt ist, das zu realisieren, was man sich vorstellt. Software ist nämlich ein göttliches Spielzeug: Was immer man möchte, kann man umsetzen. Vielleicht muss man sich dazu neue Werkzeuge entwickeln oder etwas dazulernen, aber im Prinzip sind der Fantasie keine Grenzen gesetzt. Geht nicht gibt's nicht. Die Folgen kennen wir alle: Ständig werden neue wunderbare Anwendungen entwickelt, beispielsweise im Internet. Leider besteht Programmieren nur zu einem kleinen Teil aus der Erfindung neuer Eigenschaften und Techniken, sondern zum großen Teil aus der Fehlersuche. Das ist der unangenehme Teil. Es gibt keine Software, sofern sie nicht absolut trivial ist, bei der man sich sicher sein könnte, dass sie fehlerfrei ist. Es gibt keine Möglichkeit, die Fehlerfreiheit einer Software nachzuweisen, praktisch nicht, und möglicherweise sogar theoretisch nicht, da bin ich mir nicht sicher, aber ich halte es nicht für ausgeschlossen. Deshalb muss man Software testen. Man kann das teilweise automatisieren, aber das muss natürlich auch wieder programmiert werden und ist daher fehlerträchtig. Es gibt noch einen zweiten Grund, warum das Testen so schwierig ist: Bevor man etwas testen kann, muss man sich einen Test ausdenken. Man muss also von vornherein alle Möglichkeiten berücksichtigen, unter denen eine Software genutzt werden könnte. Und das ist so gut wie unmöglich. Wenn man dann einen Fehler gefunden hat, muss man ihn beseitigen. Das nennt man debuggen, also so viel wie entwanzen, ein anschaulicher Begriff, der angeblich dadurch entstanden ist, das man bei den ersten Computern, die ja noch mit Röhren betrieben wurden, mitten zwischen den Röhren ein totes Insekt gefunden hatte, was dann zur fehlerhaften Strömen geführt und Fehler verursacht haben soll. Dieser Vorgang kann sehr schwierig und umständlich sein. Zunächst hat man den Fehler, und hoffentlich kann man diesen Fehler reproduzieren, das heißt man kann unter bestimmten Umständen garantiert den Fehler hervorrufen. Wenn das nicht möglich ist, wenn der Fehler nur manchmal auftritt, ist es fatal. Das kennen Sie alle. Das Auto funktioniert nicht, Sie fahren zur Werkstatt, können den Fehler aber nicht reproduzieren. Was soll die Werkstatt machen? Wenn der Fehler einwandfrei reproduziert werden kann, ist es nur eine Frage der Zeit, bis man die Ursache gefunden hat. Dazu muss man den Fehler im Regelfall ganz langsam einkreisen. Man versucht das Programm an einer Stelle zu stoppen, wo der Fehler noch nicht auftritt. Der Fehler muss also danach ausgelöst werden. Genauso gut kann man auch von hinten anfangen: Wenn man eine Stelle hat, wo der Fehler schon aufgetreten ist, muss er davor ausgelöst worden sein. Auf diese Weise kreist man den Fehler ein und erkennt irgendwann, wo man eingreifen muss, um diesen Fehler zu beseitigen. Reparatur Es geht bei der Reparatur verschiedene Möglichkeiten: Man kann eine schnelle Lösung herbeiführen, man kann eine grundsätzliche Lösung entwickeln, man kann das gesamte Design umwerfen, man kann das gesamte Programm neu schreiben. Ich habe heute morgen beispielsweise eine falsche Entscheidung getroffen, wie mir erst jetzt aufgeht. Ich habe an verschiedenen Stellen in meinem Programm eingegriffen, um den Mechanismus trotz der Verkürzung der Rassebezeichnung aufrechtzuerhalten. Das war aber im Grunde ein Fehler. Ich wollte doch nur das Label verkürzen, damit das Ganze schön aussieht, und hätte keineswegs die Webadresse auch noch kürzen müssen. Man muss sich also auch noch Gedanken darüber machen, ob es verschiedene Möglichkeiten gäbe den Fehler zu beseitigen, und welche davon die bessere wäre. Denn mit jeder Änderung führt man wiederum die Möglichkeit neuer Fehler ein. Das ist das Vertrackte an der Sache: Die alten Fehler sind zwar beseitigt, aber dabei hat man möglicherweise neue Fehler eingeführt, die möglicherweise sogar noch unangenehmer sind als die alten. Wenn man sich das vor Augen führt, kann man schnell die Lust am Programmieren verlieren. Aber im Grunde hat das alles nichts mit dem Programmieren zu tun. Im gesamten Leben geht es so zu: Wir müssen ständig Entscheidungen treffen und machen dabei Fehler. Diese Fehler können wir manchmal korrigieren, manchmal nicht. Bei der Korrektur eines Fehlers können wir wieder neue Fehler machen. Denken Sie beispielsweise an den Gesetzgebungsprozess. Der Gesetzgeber möchte etwas verbessern. Er entwirft ein Gesetz und versucht dabei alle Eventualitäten zu berücksichtigen. Dieses Gesetz wird dann lang und breit diskutiert und dabei werden möglicherweise Fehler aufgedeckt und beseitigt. Schließlich tritt das Gesetz in Kraft. Das ist jetzt der ultimativen Praxistest, und dabei wird deutlich, dass das Gesetz nicht das leistet, was es leisten soll. Also bessert der Gesetzgeber nach. Und das ist ein Prozess, der gar nicht zum Ende kommt. Das beste Beispiel ist die deutsche Steuergesetzgebung, ein einzigartiges Wunderwerk:
Sehr anschaulich beschrieben wird dieser Mechanismus der ständigen Nachbesserung unter » 3.1.1.: Wählerbestechung und Privilegien. Aber lassen Sie sich nicht entmutigen: Das ist alles nur menschlich, und weil es menschlich ist, kann man es ändern. Man muss nur wollen. Programmierer fangen eines Tages einfach wieder von vorne an. Sie wissen dann, was das Programm können soll, welche Anforderungen genau gestellt werden, und versuchen diese so schlank wie möglich umzusetzen. Das ist aber auch nichts Besonderes. Man baut schon seit 100 Jahren Autos, aber immer wieder fangen die Autohersteller ganz von vorne an, statt die alten Modelle weiter zu verbessern. Spam Der Spam der Woche: Hallo, Errors! Schnell und diskret...
Haiku
Spruchweisheit » Die Vision - unmöglich?
|
» Perikles
» Bandbreitenmodell| › voriges Editorial | › Ãœbersicht Editorials | › nächstes Editorial | › Ausgabe 639 |
|
›Autorenhinweise
›Kontakt
›Impressum
›Konditionen
|
+49 30 86436672
|
|
