M/Ph/Info (Beslmeisl)

Auf dieser Seite lesen Sie, wie ich mich dazu bringe, Fehler zu vermeiden oder nicht vermiedene Fehler aufzuspüren. Natürlich bin ich unheimlich schlau und erfahren und mache keine Fehler. Jedoch gibt es immer wieder Momente, wo mein Unterbewusstsein dies ignoriert und mich wie einen Deppen dastehen lässt.

Wenn Sie im Laufe des Unterrichts den Eindruck gewinnen, dass Sie mehr Fehler machen als ich und auch noch länger brauchen, um sie zu finden, dann ist dieser Abschnitt für Sie interessant.

• Ich achte immer strengstens auf korrekte Einrückung. Da ich meinen Editor gut beherrsche, fällt mir das nicht schwer. Beherrsche deinen Editor!
• Alles was ich schreibe, muss spätestens wenige Minuten nach dem aktuellen Schreibvorgang schon wieder kompilierbar sein.
• Die main-Methode ist das erste, was ich schreibe. Sie erzeugt Hilfsobjekte, mit denen ich die anderen Methoden teste. Ganz am Schluss wird die main entfernt. Sie gehört normalerweise nicht in eine Klassendatei. Nur in einem Hauptprogramm ganz am Schluss eines Projektes braucht man sie wirklich, bei der Entwicklung aber nur zwischendurch.
• Ich versuche, zu jeder Zeit möglichst wenige Methoden (idealerweise nur eine einzige) zu bearbeiten und parallel aus der main heraus zu testen. (In der 11. Klasse bin ich die meiste Zeit sowieso nur in der main.)
• Während der Testphase sind Schweinereien erlaubt. Am Ende müssen die aber raus aus der Klasse. System.out.println ist normalerweise eine Schweinerei, die höchstens in einer static-Methode eine Existenzberechtigung hat.

Der Entwicklungszyklus ist die Abfolge von Tätigkeiten, die man durchläuft, während man ein Programm implementiert (schreibt).

Wenn man Glück hat, hilft einem der Compiler ausreichend, um alle Probleme zu finden und zu beheben. Das ist bei einfachen Programmen, wie sie in der Schule auftreten, oft der Fall.

1. Starten der benötigten Programme: In einfachen Fällen (Schulbeispiele) reicht da ein Konsolenfenster und ein Editor. Ich öffne also ein Konsolenfenster und navigiere an die Stelle, wo das Programm liegen soll. Vielleicht muss ich noch ein Verzeichnis anlegen. Wenn ich mich im Zielverzeichnis befinde, öffne ich aus der Konsole heraus meinen Lieblingseditor. Den Dateinamen der zu bearbeitenden Datei gebe ich gleich an, das spart Zeit!
2. Ich schreibe das Klassengerüst mit einer main-Methode. Die brauche ich, um alles zu testen. Wenn das Projekt aus mehreren Klassen besteht, werde ich diese main wahrscheinlich am Ende wieder löschen. Aber das Ende ist fern.
3. Ich speichere und kompiliere. Falls etwas schief gelaufen ist, ist es nicht viel und ich werde den Fehler leicht finden.
4. Ich verändere die Datei, füge Neues hinzu. Aber nicht viel, ein paar Zeilen vielleicht. Insbesondere bewege ich mich in der Datei nur an wenige Stellen, am besten nur eine.
5. Ich speichere und kompiliere. Falls etwas schief gelaufen ist, ist es nicht viel und ich werde den Fehler leicht finden.
   • Ich starte das Programm, um zu sehen, ob es korrekt funktioniert. Gut, dass das Programm eine main-Methode hat, sonst könnte ich es nicht starten.
   • Ich gebe beim Start gern Argumente auf der Kommandozeile mit, weil das schnell und unkompliziert geht. Natürlich musste ich hierfür in der main ein paar Zeilen schreiben, um die Argumente auch entgegennehmen und vielleicht umwandeln. Diese kleine Zusatzarbeit mache ich mir aber gern, weil danach alles viel schneller geht.
6. Wenn es Fehlermeldungen gibt, lese ich die erste aufmerksam und überfliege die anderen meist nur. Oft ist es nur ein Fehler, der zu vielen Meldungen führt.
   • Ich denke über die erste Meldung genau nach. Wenn ich sie verstanden habe, habe ich einen Fehler gefunden.
   • Wenn es ein logischer Fehler ist, dann probiere ich nicht herum, sondern denke nach. Herumprobieren führt oft dazu, dass das Programm etwas scheinbar richtig macht. Dafür verhält es sich aber gerade deswegen an einer anderen Stelle falsch. Weil ich nur herumprobiert habe, habe ich aber nichts verstanden und bin noch verwirrter als zuvor.
7. Wenn ich fertig bin, höre ich auf. Andernfalls weiter bei 4.

Bei halbwegs interessanten Programmen stößt man auf Fehler, die man nicht durch einfaches Lesen des Programmtextes herausfindet. Dann muss das Denken aus der aktuellen Bahn katapultiert werden. Die aktuelle Bahn fühlt sich super angenehm an. Man glaubt, dass man den vollen Überblick hat und dass der Computer böswillig ist. Das ist falsch.

1. Ich baue System.out.println-Befehle ein, um an wichtigen Stellen zu überprüfen, ob wirklich das rauskommt, was ich erwarte. Damit kann man einen Fehler sehr gut verfolgen, weshalb diese unscheinbare Technik auch bei Spitzenleuten die beliebteste ist.
2. Ich erkläre mein Programm einem kritischen Zuhörer. Dessen Zwischenfragen bringen mich auf das Problem oder ich merke während der Erklärung, dass ich Mist erzähle und der Fehler ist gefunden.
3. Als letzten Ausweg debugge ich das Programm. Dafür brauche ich eine Entwicklungsumgebung, die mir erlaubt, alle Variableninhalte zu beobachten, während ich Schritt für Schritt die Zeilen abarbeite. Das macht sogar eine Menge Spaß. Unangenehm ist nur, dass es so lange dauert und dass ich NetBeans starten muss. NetBeans braucht die Dateien aber an einer bestimmten Stelle, was zusätzlich Arbeit macht. Der JavaEditor ist eine Zwischenlösung: Der startet schneller, hat aber keine so schönen Anzeigemöglichkeiten.