Benutzer-Werkzeuge

Webseiten-Werkzeuge


info:java:cycle

Dies ist eine alte Version des Dokuments!


Den Deppen bremsen

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.

Verhaltensregeln

  • Ich achte strengstens auf Einrückungen, und zwar immer! Dafür muss ich meinen Editor beherrschen, andernfalls fällt es mir so schwer, dass ich nicht den Mut dazu habe.
  • 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.

Entwicklungszyklus

  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.
  6. 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.
  7. Wenn es Fehlermeldungen gibt, lese ich meist nur die erste aufmerksam und überfliege die anderen 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 meinen 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.
info/java/cycle.1284285712.txt.gz · Zuletzt geändert: 2010/09/12 12:01 von admin