Strukturiertes Vorgehen beim Programmieren in Java

Worum geht´s?

In diesem Tutorial lernst du drei Werkzeuge kennen, die dir helfen, beim Programmieren strukturierter vorzugehen:

• Pseudo-Code
• Ablaufdiagramme
• Schreibtischtest

Alle drei helfen dir, dein Programm schon bevor du es tatsächlich programmierst möglichst klar zu visualisieren.

Auch wenn die Werkzeuge etwas Zeit verbrauchen, holst du die hier investierte Zeit meist mehrfach wieder rein, wenn es dann ums „eigentliche“ Programmieren in Java geht.

1. Pseudo-Code

Pseudo-Code ist Programmier-Code, der sich nicht darum schert, ob er wirklich 100% richtig geschrieben ist.

Es geht nur darum dass klar ist, was in etwa in einem Algorithmus passiert – etwa wo die ifs und die Schleifen sind, und was diese machen.

Du kannst dir beim Pseudo-Code auch Fantasie-Funktionen ausdenken, die es gar nicht gibt, um dein Programm einfacher zu machen. Später kannst du ja immer noch genau diese Funktionen nachprogrammieren, falls der Rest funktioniert.

Mit Hilfe von Pseudo-Code kannst du auf dem Papier in relativ kurzer Zeit eine grobe Idee bekommen, wie dein Algorithmus später funktionieren soll.

Hier ein Beispiel für die Berechnung aller Primzahlen von 1 bis 1000:

Gehe alle Zahlen von 1 bis 1000 durch
Für jede dieser Zahlen schau dir an, ob man sie durch mehr als sich selbst und eins teilen kann
Wenn ja, ist es keine Primzahl, also mach nichts
Wenn nein, ist es eine Primzahl, also gib sie aus.

Ist noch sehr grob, das Ganze. Noch etwas verfeinert:

Gehe alle Zahlen von 1 bis 1000 durch
Für jede dieser Zahlen n schau dir an, ob man sie durch mehr als sich selbst und eins teilen kann (überprüfe alle Zahlen x von 2 bis zu der Zahl n, ob n % x == 0)
Wenn durch eine Zahl teilbar war, ist es keine Primzahl, also hör auf zu suchen und geh zur Zahl n+1
Wenn von x = 2 bis (n-1) nichts teilbar war, ist es eine Primzahl, also gib sie aus.

Das taugt schon mehr. Daraus kann man dann schon Java-Code machen:

public class HelloWorld {
    public static void main(String[] args) {
        for (int n = 1; n <= 1000; n++) {
            boolean prim = true;
            for (int x = 2; x < n && prim; x++) {
                if (n % x == 0) {
                    // keine Primzahl -> beende innere for-Schleife
                    prim = false;
                }
            }
            if (prim)
                System.out.println("[" + n + "]");
        }
    }
}

2.  Ablauf-Diagramme

Ablauf-Diagramme funktionieren ähnlich wie Pseudo-Code, nur eher grafisch.

Hier zum Beispiel ein Ablauf-Diagramm für einen Wecker (von online.visual-paradigm.com):

Die Idee ist es, die wichtigsten Teile des Algorithmus abzubilden – was kommt wann, unter welcher Voraussetzung. Nicht jeden einzelnen Befehl also, sondern wie beim Pseudo-Code nur den groben Ablauf.

Grundsätzlich gibt es einige Konventionen, welche Teile des Diagramms wie aussehen:

Start/Stopp des Programms: Kreise
Entscheidungen (IF/ELSE, SWITCH): Raute, Mehrere Pfeile ausgehend
Schleifen (WHILE, DO-WHILE, FOR): Pfeile zurück zu früherem Element
Eingabe/Ausgabe (Scanner): Parallelogramm
Alle anderen Befehle (z.B. Berechnungen, …): Rechteck

Aber in den den meisten Fällen ist es eigentlich egal – hauptsache, man kennt sich aus.

3. Schreibtischtest

Ein Schreibtischtest „spielt Computer“ – das heißt, man probiert das Programm mit Zettel und Stift aus.

Meistens über eine Art von Tabelle, in der man einträgt, welche Variablen zu welchem Zeitpunkt welche Werte haben (wenn mans ganz genau haben will, auch in welcher Code-Zeile das geschieht).

4. Und jetzt alle…!

Ich für meinen Teil verwende im Alltag alle drei dieser Techniken, nur oft wild durcheinander.

Den Schreibtischtest dafür mir zu überlegen, welche Variablen in welcher Reihenfolge welche Werte annehmen sollten. Meist sogar als ersten Schritt.

Dann ein Ablauf-Diagramm, gemischt mit etwas Pseudo-Code, um den zukünftigen Algorithmus grob „vorzuzeichnen“. Hier findet auch schon die erste Optimierung statt, falls sich schon eine entdecken lässt.

Dann versuche ich meist, den groben Algorithmus in IntelliJ zu übertragen, ob er funktioniert.

Wenns gar nicht klappt, geht’s wieder zurück zu Zettel und Stift. Entweder, um den bestehenden Algorithmus zu optimieren, oder um gleich einen ganz neuen Versuch zu wagen.

Oft ist es nämlich effizienter, gleich neu anzufangen, anstatt einen vermurksten Algorithmus retten zu wollen.

Über die Jahre habe ich die Erfahrung gemacht, dass es zwar etwas Extra-Aufwand ist, mit Zettel und Stift zu arbeiten, dieser Extra-Aufwand sich insgesamt massiv auszahlt. Im Sinne von bis zu 80% weniger Zeit, die alles insgesamt braucht. Die Zeit, die einspart, wenn man die „Zettel-Phase“ überspringt, braucht man dann nämlich oft 5x so lang beim „eigentlichen“ Programmieren in IntelliJ.

Es zahlt sich also aus 🙂

Diskussion zum Tutorial