M/Ph/Info (Beslmeisl)

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
=====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 **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.

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

===Der glückliche, einfache Fall===
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.
  - 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!
  - 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.
  - Ich speichere und kompiliere. Falls etwas schief gelaufen ist, ist es nicht viel und ich werde den Fehler leicht finden.
  - 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.
  - 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.
  - 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.

===Der Normalfall===
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.
  - 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.
  - 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.
  - 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.
M/Ph/Info (Beslmeisl)

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Seiten-Werkzeuge
