19.2.2001

XP über die Schulter geschaut

Ein erster Einblick

Wie sieht ein Tag mit Extreme Programming aus? Nun, Sie werden wie gewohnt programmieren. Obwohl, nicht ganz. Sie programmieren mit einem Partner. Sie arbeiten zu zweit an einer kleinen überschaubaren Aufgabe. Die Zerlegung in Aufgaben haben Sie kurz zuvor im Team in einem kurzen Design-Meeting mit dem Kunden diskutiert und geplant. Sie haben die Verantwortlichkeit für eine Reihe von Aufgaben akzeptiert und suchen sich für deren kurze Dauer jeweils einen Programmierpartner.

Bevor Sie gemeinsam zu programmieren beginnen, analysieren Sie und Ihr Partner zunächst, was Ihr Auftraggeber überhaupt an Anforderungen stellt. Dazu möchten Sie unter Umständen direkt mit Ihrem Kunden sprechen. Er arbeitet wenige Meter von Ihnen beiden entfernt im gleichen Büro, damit Fragen des Entwicklungsteams unmittelbar diskutiert werden können.

Jetzt wissen Sie beide, was verlangt wird, und Sie können endlich losprogrammieren. Einen Augenblick. Bevor Sie losprogrammieren, überlegen Sie und Ihr Partner sich zunächst ein Design dafür, wie die Anforderungen überhaupt umgesetzt werden sollen. Dazu schreiben Sie eine Reihe von Testfällen. Anschliessend schreiben Sie den Code, der diese Tests erfüllt. Dabei streben Sie stets die einfachste Lösung an. Testfall für Testfall erhalten Sie grünes Licht und gehen weiter. Die Aufgabe gilt dann als erledigt, wenn Ihnen beiden keine weiteren Tests mehr einfallen, die sich für die aktuellen Anforderungen sinnvoll schreiben liessen.

Wenn alle Ihre Tests erfüllt sind, verlangt XP von Ihnen, den geschriebenen Code noch möglichst zu vereinfachen und sein Design zu verbessern. Der Code darf unter anderem keine duplizierte Logik enthalten und muß jede Intention ausdrücken, die für das Verständnis des Programms notwendig erscheint. Nachdem Sie den Code in Form gebracht haben, lassen Sie Ihre Arbeit durch die Suite aller im Team gesammelten Tests kontrollieren und integrieren schließlich Ihren geschriebenen Code mit den Änderungen Ihrer Teamkollegen. Anschliessend besorgen Sie sich zunächst einmal frischen Kaffee und helfen eventuell direkt Ihrem Partner bei seiner nächsten Programmieraufgabe.

Ein XP-Tag geht schnell vorüber, da Sie den ganzen Tag lang intensiv mit Ihren Kollegen programmiert haben. Das bedeutet nicht etwa, daß Sie Ihrem Partner bei der Arbeit über die Schulter schauen. Im Gegenteil. Im Paar zu programmieren bedeutet aufmerksam in die Programmierepisode involviert zu sein. Sie unterhalten sich über den Code, den sie gemeinsam schreiben. Regelmässig übergeben Sie Ihrem Partner die Tastatur und lassen ihn "fahren". Am Ende eines solchen Tages sind Sie erschöpft und, glauben Sie mir, Sie gehen pünktlich nach Hause, weil Sie acht Stunden lang fokussiert gearbeitet haben und die geschriebenen Tests Ihnen Vertrauen in die geleistete Arbeit geben.

Zugegeben, der Name "Extreme Programming" läßt einen extrem einseitigen Ansatz der Softwareentwicklung vermuten. Auf den zweiten Blick jedoch widmet sich XP sehr viel intensiver der Analyse, dem Design und dem Test als schwergewichtige Methoden. XP bringt uns zurück zu den Wurzeln des Handwerks guter Programmierung und der Fragestellung, was wirklich zählt, wenn wir hochqualitative Software erstellen wollen.

Ich möchte Sie dazu einladen, das Handwerk von XP und das Lebensgefühl eines leichtgewichtigen Prozesses kennenzulernen. Begleiten Sie mich auf den folgenden Seiten durch ein XP-Projekt und schauen Sie dem Team bei der täglichen Arbeit über die Schulter und in die Karten.

Programmieren in Paaren

Die Regel lautet: Wer um Hilfe bittet, dem wird Hilfe geboten. Tatsächlich wird keine Zeile Produktionscode geschrieben, ohne daß zwei Paar Augen auf den Bildschirm gerichtet sind. Das bedeutet, Sie programmieren zu zweit an einem Rechnern mit einer Tastatur und einer Maus. Sie sitzen nebeneinander, führen ein intensives Gespräch über den entstehenden Code und wechseln sich regelmässig an der Tastatur ab. Sie dürfen dabei sogar Spaß haben, denn Programmieren soll Spaß bringen. Sie wechseln häufiger Ihre Programmierpartner und am Ende der Woche haben Sie idealerweise mal mit jedem Ihrer Kollegen zusammengearbeitet, damit sich das aufgebaute Wissen über das gesamte Team verbreitet.

Felix und Ulrich, Dienstag, 1.Iteration, 11.03 Uhr

Ulrich: Was ist unsere Aufgabe?

Felix: Wir müssen die Miete für ausgeliehene DVDs berechnen.

Ulrich: Wie berechnen wir das?

Felix: Der Preis ist abhängig davon, wie lange eine DVD ausgeliehen wird.

Ulrich: Und wie?

Felix: Laß mich mal sehen... Auf unserer Karte steht, reguläre Filme kosten für zwei Tage 2 Euro. Ab dem dritten Ausleihtag dann 1.5 Euro pro Tag.

Ulrich: Okay, wie machen wir das also?

Felix: Mmm, ich schlage vor, wir merken uns zunächst mal, welche Filme ein Kunde ausleiht und berechnen später die Miete anhand der Ausleihtage.

Ulrich: Warum berechnen wir die Kosten nicht auf der Stelle?

Felix: Das ist später vielleicht notwendig, aber momentan ist das keine Anforderung.

Ulrich: Schön, wie soll unsere erste Klasse heissen?

Felix: Spannende Frage... Die Verantwortlichkeiten klingen fast danach, als würde sich die Klasse selbst Customer nennen wollen.

Ulrich: Fangen wir damit mal an.

Felix: Stop mal! Laß uns gleich einen Test dafür schreiben...

Ulrich: Gut, dazu muß unsere Testklasse von TestCase aus dem Test-Framework ableiten.

Felix: Und dann bekommt sie noch einen Konstruktor für den Namen des Testfalls.


public class CustomerTest extends junit.framework.TestCase {
  public CustomerTest(String name) {
    super(name);
  }
}

Testgetriebenes Programmieren

Die anzustrebende Geisteshaltung muß sein, daß eine Funktion solange nicht existiert, bis sie einen automatisierten Test besitzt. Tatsächlich entsteht kein Produktionscode, bevor es nicht einen entsprechenden Testfall gibt, der fehlschlägt. Das bedeutet, Sie schreiben einen Test noch bevor Sie den Code schreiben, der diesen Test erfüllt. Sie erstellen inkrementell eine umfassende Suite von Unit Tests, die das gesamte Programm in isolierten Einheiten auf die erwartete Funktion hin überprüft. Sie verwenden ein Test-Framework, das Ihnen dabei hilft, automatische Tests zu schreiben und auszuführen. Sie sammeln und pflegen diese Tests, damit Sie nach jeder Änderung sicherstellen können, daß die Testsuite zu 100% läuft.

Ulrich: Was ist der erste Testfall?

Felix: Das einfachste wäre, wir fangen mit dem Ausleihen eines Films an.

Ulrich: Und wie?

Felix: Es ist so, daß wir für jede Methode, die funktionieren soll, Zusicherungen schreiben wollen, um die Funktion abzuprüfen.

Ulrich: Dafür ist die assertTrue Methode gedacht, die wir aus TestCase erben.

Felix: Genau. Als Parameter erwartet sie eine Bedingung, die true ergeben muß, damit der Testfall als erfüllt gilt. Den Rest erledigt das Framework.

Ulrich: Und wohin schreiben wir nun den Testcode?

Felix: Am besten schreiben wir dafür eine Testfallmethode testRentingOneMovie, die dann die Mietkosten für den Film testet. Das Framework findet automatisch alle Methoden, die mit test beginnen, und führt sie aus.

Ulrich: Gut, schreiben wir mal auf, was wir bis jetzt wissen. Wir benötigen zunächst mal ein Customer Exemplar. Und dann muß ich so tun, als gäbe es einfach alle Methoden schon, die ich mir wünsche.

Felix: Richtig. Wir leihen eine DVD für einen Tag aus und es soll 2 Euro kosten.

Ulrich: Das ist einfach.


public class CustomerTest...
  public void testRentingOneMovie() {
    Customer customer = new Customer();
    customer.rentMovie(1);
    assertTrue(customer.getTotalCharge() == 2);
  }
}

Möglichst einfaches Design

Die Designstrategie sieht vor, mit einem schlichten Design zu starten und dieses fortlaufend zu verbessern. Tatsächlich werden Designelemente, die komplizierter sind, als momentan unbedingt notwendig wäre, aufgeschoben, selbst wenn nur für wenige Minuten. Das bedeutet, Sie wählen von vielen verschiedenen Lösungswegen denjenigen, der am einfachsten erscheint, um einen Testfall zu erfüllen. Sie programmieren nur, was Sie jetzt tatsächlich benötigen, nicht, was Sie später vielleicht benötigen. Sie gehen sogar soweit, daß Sie unnötige Flexibilität wieder aus dem Code entfernen. Sie treten den Beweis dafür an, daß die aktuelle Lösung zu einfach ist, indem Sie einen Testfall schreiben, der ein komplexeres Design rechtfertigt.

Ulrich: Also gut. Du willst, daß ich nur den Test zum Laufen bringe und alles andere für einen Moment vergesse.

Felix: Ganz genau. Was würdest Du tun, wenn Du nur diesen einen Test implementieren müsstest?

Ulrich: Hah, auch das ist einfach.


public class Customer {
  public void rentMovie(int daysRented) {
  }

  public int getTotalCharge() {
    return 2;
  }
}

Felix: Wie extrem! Aber gut...

Ein wenig Testen, ein wenig Programmieren...

Das Zusammenspiel von testgetriebenem Programmieren und einfachem Design ergibt den Zyklus des minutenweisen Programmierens. Tatsächlich wird nie länger als zehn Minuten programmiert, ohne die Feedbackschleife unmittelbar durch konkrete Tests zu schliessen. Das bedeutet, Sie schreiben neuen Code in so winzigen Schritten, daß Ihr Code gerade mal den aktuellen Testfall erfüllt. Sie testen ein wenig, Sie programmieren ein wenig. Dann testen Sie wieder und programmieren... Minute für Minute feiern Sie einen kleinen Erfolg. Sie schreiben keine ganze Klasse in einem Rutsch. Vielmehr schreiben Sie nur ein paar Zeilen Code, maximal eine Methode auf einmal.

Ulrich: Als nächstes möchte ich zwei und drei ausgeliehene DVDs testen.

Felix: Immer langsam... Schreib erst mal den Test für zwei Filme. Der Zweite wird für zwei Tage entliehen. Die Summe soll 4 Euro betragen. Laß uns dazu die assertEquals Methode benutzen. Als Parameter erhält sie den erwarteten Wert und das tatsächliche Resultat.


public class CustomerTest...
  public void testRentingTwoMovies() {
    Customer customer = new Customer();
    customer.rentMovie(1);
    customer.rentMovie(2);
    assertEquals(4, customer.getTotalCharge());
  }
}

Ulrich: Okay, dieser Test wird nicht laufen.

Felix: Woher weisst Du das? Schau nach, Du weisst nie!

Ulrich: Sagen wir einfach, ich bin mir ziemlich sicher.

Felix: Gut, wenn Du es also weisst und nehmen wir an, der Test zeigt grün, würde das demnach bedeuten, daß entweder unser Test falsch ist oder aber der Code Dinge tut, die er nicht machen darf, richtig? Mach den Test!

Ulrich: Also gut... Der Test zeigt rot.

Felix: Diesmal kommst Du auch nicht mehr so einfach davon...


public class Customer {
  private int totalCharge = 0;

  public void rentMovie(int daysRented) {
    totalCharge += 2;
  }

  public int getTotalCharge() {
    return totalCharge;
  }
}

Evolutionäres Design

Organisches Wachstum scheint eine gute Strategie zu sein, um auf Veränderung und Ungewissheit reagieren zu können. Tatsächlich werden Anforderungsänderungen als Chance und nicht als Problem betrachtet. Das bedeutet, Sie verhalten sich im Design so, als wüssten Sie wirklich nicht, was die nächsten Anforderungen sein würden. Sie entwerfen stets die einfachste Lösung und bringen Ihren Code anschliessend in die einfachste Form. Sie vertrauen auf die Tatsache, daß sauber strukturierter Code in jede Richtung mitziehen kann und daß der Code, den Sie gestern geschrieben haben, Sie heute und morgen dabei unterstützen wird, weiterhin Code zu schreiben, und Sie nicht zunehmend daran hindert.

Ulrich: Was ist der nächste Testfall?

Felix: Ein dritter Film, der drei Tage entliehen wird.

Ulrich: Wieviel kostet der Film, wenn er erst nach drei Tagen zurückgegeben wird?

Felix: Jeder weitere Tag kommt auf 1.5 Euro.

Ulrich: Also 3.5 Euro am Tag drei. Macht zusammen 7.5 Euro. Ausserdem können wir Fließkommazahlen nicht mit unendlicher Genauigkeit vergleichen.


public class CustomerTest...
  public void testRentingThreeMovies() {
    Customer customer = new Customer();
    customer.rentMovie(1);
    customer.rentMovie(2);
    customer.rentMovie(3);
    assertEquals(7.5, customer.getTotalCharge(), 1e-3);
  }
}

Felix: Ab jetzt müssen wir 1.5 Euro draufschlagen.

Ulrich: Das bedeutet auch, daß totalCharge ab sofort Fließkommazahl sein möchte.


public class Customer {
  private double totalCharge = 0;

  public void rentMovie(int daysRented) {
    totalCharge += 2;
    if (daysRented > 2) {
      totalCharge += 1.5;
    }
  }

  public double getTotalCharge() {
    return totalCharge;
  }
}

Felix: Nun meckert aber der Compiler rum... Wir müssen wohl auch unseren vorherigen Testfall zum Vergleich von Fließkommazahlen bringen.


public class CustomerTest...
  public void testRentingTwoMovies() {
    Customer customer = new Customer();
    customer.rentMovie(1);
    customer.rentMovie(2);
    assertEquals(4, customer.getTotalCharge(), 1e-3);
  }
}

Natürlicher Abschluß einer Programmierepisode

Bewußt aufhören zu können ist einer der stärksten Programmierzüge. Tatsächlich ist eine Aufgabe fertig, wenn alle Randbedingungen getestet sind, die dazu führen können, daß etwas schief geht. Das bedeutet, Sie schreiben nicht für jede Methode einen Test, sondern nur für solche, die unter Umständen fehlschlagen könnten. Sie halten Ihr Wissen über den Code fest, während Sie Tests dafür schreiben. Sie wissen, daß Sie erreicht haben, was Sie sich vorgenommen hatten, wenn alle Ihre Tests erfüllt sind. Zum Abschluß sei es Ihnen gegönnt, über Ihre Programmierepisode zu reflektieren. Sie wollen ja schließlich jeden Tag etwas dazulernen.

Ulrich: Ein Film, der vier Tage entliehen wird?

Felix: Kostet 5 Euro und macht dann insgesamt 12.5 Euro.


public class CustomerTest...
  public void testRentingFourMovies() {
    Customer customer = new Customer();
    customer.rentMovie(1);
    customer.rentMovie(2);
    customer.rentMovie(3);
    customer.rentMovie(4);
    assertEquals(12.5, customer.getTotalCharge(), 1e-3);
  }
}

Felix: Laß mich mal tippen!

Ulrich: Okay!


public class Customer...
  public void rentMovie(int daysRented) {
    totalCharge += 2;
    if (daysRented > 2) {
      totalCharge += (daysRented - 2) * 1.5;
    }
  }
}

Felix: So, das hätten wir. Haben wir irgendwelche Tests vergessen?

Ulrich: Müsste mit dem Teufel zugehen...

Refactoring

Gutes Design ist nie einfach und niemand bekommt die Dinge im ersten Versuch in den Griff. Tatsächlich entsteht ein Design durch schrittweises Wachstum und ständige Überarbeitung. Das bedeutet, daß Sie alle Erfahrungen in das Design zurückfliessen lassen und das Design verbessern, nachdem der Code geschrieben wurde. Sie refaktorisieren, um Ihren Code so einfach und so verständlich wie möglich zu machen und jede Art von Redundanz zu beseitigen.

Ulrich: Wenn ich mir unseren Code ansehe, frage ich mich, was die vielen Zahlen bedeuten. Wir sollten denen Namen geben!

Felix: Vorschläge?


public class Customer...
  static final double BASE_PRICE = 2;       // Euro
  static final double PRICE_PER_DAY = 1.5;  // Euro
  static final int DAYS_DISCOUNTED = 2;
}

Ulrich: Eigentlich finde ich die Änderung ja zu klein, um nach jedem Schritt zu testen...

Felix: Du hast Mut, aber wir haben ja noch die Tests...


public class Customer...
  public void rentMovie(int daysRented) {
    totalCharge += BASE_PRICE;
    if (daysRented > DAYS_DISCOUNTED) {
      totalCharge += (daysRented - DAYS_DISCOUNTED) * PRICE_PER_DAY;
    }
  }
}

Ulrich: Irgendwie passen die Konstantennamen nun aber doch nicht mehr zu der Klasse.

Felix: Stimmt, das hat jetzt schon sehr viel mit der eigentlichen Preisberechnung für den Film zu tun.

Ulrich: Ziehen wir eine neue Klasse Movie raus, um dem Ausdruck zu verleihen!?

Felix: Einverstanden, aber erst die Tests...


public class MovieTest extends junit.framework.TestCase {
  public MovieTest(String name) {
    super(name);
  }

  public void testGetCharge() {
    assertEquals(2.0, Movie.getCharge(1), 1e-3);
    assertEquals(2.0, Movie.getCharge(2), 1e-3);
    assertEquals(3.5, Movie.getCharge(3), 1e-3);
    assertEquals(5.0, Movie.getCharge(4), 1e-3);
  }
}

Felix: Die Preisberechnung verschieben wir einfach auf diese Klasse...


public class Movie {
  static final double BASE_PRICE = 2;       // Euro
  static final double PRICE_PER_DAY = 1.5;  // Euro
  static final int DAYS_DISCOUNTED = 2;

  public static double getCharge(int daysRented) {
    double result = BASE_PRICE;
    if (daysRented > DAYS_DISCOUNTED) {
      result += (daysRented - DAYS_DISCOUNTED) * PRICE_PER_DAY;
    }
    return result;
  }
}

Felix: Unser Customer wird dadurch wieder ganz schlank...


public class Customer...
  public void rentMovie(int daysRented) {
    totalCharge += Movie.getCharge(daysRented);
  }
}

Fortlaufende Integration

Neuer Code wird schnellstmöglich in die neueste Version integriert. Tatsächlich wird mehrmals täglich ein getesteter Build des gesamten Programms erstellt. Das bedeutet, daß Sie am Ende jeder Programmierepisode und wenigstens einmal am Tag Ihren geschriebenen Code in das Programm integrieren und versionieren. Sie laden Ihre Änderungen auf einen dedizierten Integrationsrechner, integrieren Ihren Code und beseitigen entstehende Konflikte. Sie führen die Tests aus und geben Ihren Code frei, sobald alle Tests erfolgreich ausgeführt werden. Die gesamte Integrationsprozedur dauert gerade so lange, daß Sie sich eine frische Tasse Kaffee kochen und sie austrinken können.

Felix: Laß uns unseren Code integrieren und Mittag machen!

Ulrich: Milchkaffee oder Chinese?

Nächster Artikel in dieser Serie: Unit Tests mit JUnit

Danksagungen

Leah Striker, Michael Schürig, Meike Budweg, Tammo Freese, Ulrike Jürgens, Hans Wegener, Marko Schulz, Antonín Andert, Manfred Lange und Julian Mack haben das Beispiel entstehen sehen und nützliche Verbesserungsvorschläge gemacht.

Der Ehrentitel eines Meisterrezensenten sei an Rolf F. Katzenberger verliehen.

Schlagwörter:

blättern: Agile Softwareentwicklung
zurück: Software-Expedition