Software Design PatternsExtreme Programming

(XP)

Übersicht

• entstanden im Smalltalk-Umfeld• erstmals 1997 im C3-Projekt bei Chrysler

eingesetzt• erste Publikation 1999 von Kent Beck

Name Extreme Programming

auch bekannt als Agile Methodik zur Softwareentwicklung

Typ Organisatorisches Pattern

Was verspricht XP?

• Jeden Tag an etwas zu arbeiten das wirklich wichtig (und interessant) ist

• In heiklen Situationen nicht alleine dazustehen

• Programmierzeit wird optimal genutzt

• Sichtbarkeit von Fortschritten

• Lauffähige Version nach kurzer Zeit

Dem Programmierer Dem Kunde

Probleme die XP löst

• Terminverzögerung• Projektabbruch• System wird unrentabel• hohe Fehlerrate• Geschäftsziel falsch verstanden• Geschäftsziel ändert sich• falsche Funktionsfülle• Personalwechsel

Was ist XP? (1) –Überblick

Die vier Grundwerte von XP:

• Einfachheit (simplicity)

• Kommunikation (communication)

• Feedback

• Mut (courage)

Was ist XP? (2) - Einfachheit

Kern von XP ist Einfachheit

• einfaches Code-Design• ständiges Refactoring• ständige Tests• einfache Kommunikationswege

Kosten für Änderungen gering

Was ist XP? (3) - Einfachheit

Kosten für Änderungen bei Projekten

Zeit

Au

fwan

d

traditionell

XP

Was ist XP? (4) - Kommunikation

• Programmieren in Paaren (pair programming)

• Kunde ist Vor-Ort

• Code ist Dokumentation für Programmierer

• Unit-Tests sind wichtige Dokumentation des Systems

Was ist XP? (5) - Feedback

• kurze Releasezyklen

• immer vorhandenes lauffähiges Release

• Echtzeit-Rückmeldungen durch Vorort-Kunde

• Kunde bestimmt Prioritäten

• Programmierer hat ständige Rückmeldung über Qualität des Codes durch Unit-Tests

Was ist XP? (6) - Mut

Wieso Mut?

• Produktivitätsverlust um 50% durch Programmieren in Paaren?

• Schlichtheit des Codes ist schwer zu erlernende Disziplin

• gemeinsamer Code

Die XP-Praktiken (1)

Zusammenfassung: Die 12 XP-Praktiken

• Planungsspiel (planning game)

• kurze Releasezyklen

• Metapher

• einfaches Design

• Testen

• Refactoring

Die XP-Praktiken (2)

• Programmieren in Paaren (pair programming)

• gemeinsame Verantwortlichkeit

• fortlaufende Integration

• 40-Stunden-Woche

• Kunde Vor-Ort

• Programmierstandards

Die XP-Praktiken (3)

Folgerung: Alle Praktiken stützen sich gegenseitig

Kunde Vor-Ort

Metapher40-Stunden-Woche

gemeinsameVerantwortlichkeit

Programmierstandards

Planungsspiel

fortlaufende Integration

kurze Releasezyklen

Refactoringeinfaches Design

TestenProgrammieren in Paaren

Refactoring (1)

Was ist Refactoring?

• Verbesserung des Code-Designs ohne die Funktionalität zu verändern

• Code einfach wie möglich halten

• selbstdokumentierend

hohe Kosten für Änderungen vermieden

Refactoring (2)

Beispiel – Vor Refactoring:

class Person {private String firstName;public void setFirst(String s) {

this.firstName = s;}

}

Refactoring (3)

Beispiel – bessere Namen für Argumente:

class Person {private String firstName;public void setFirst(String firstName) {

this.firstName = firstName;}

}

Refactoring (4)

Beispiel – Änderung des Methodennamens

class Person {private String firstName;public void setFirstName(String firstName) {

this.firstName = firstName;}

}

Refactoring (5)

Wie wird Refactoring durchgeführt?

1. Sicherstellen, dass Unit-Test für die zu ändernde Funktion existert

2. Änderungen durchführen

3. Unit-Tests ausführen

4. Schritte 2-4 wiederholen, bis Refactoring beendet

Refactoring (6)

• Martin Fowlers Refactoring Katalog umfasst knapp 100 Refactorings (http://www.refactoring.com/catalog/)

Refactoring (7)

alle modernen IDEs enthalten elementare Unterstützung des Refactorings:

• Abhängigkeiten von Feldern, Methoden und Klassen finden

• automatisches Umbenennen von Feldern, Methoden und Klassen

• automatisches Umwandeln von Blöcken in Methoden (extract method)

Ant (1)

Wozu ein Build-System?• konstantes Refactoring• gemeinsame Verantwortung• wechselnde Programmierpaare• unterschiedliche Konfigurationen

Bestandteil des Buildsystems „Cruise Control“ (http://cruisecontrol.sourceforge.net)

Ant (2)

Was ist Ant?• Java-basierter Ersatz für plattformspezifisches

make• Konfiguration über XML-Dateien (build.xml)• Definition von tasks: Quellcode kompilieren,

JAR-Archive erstellen, Deployment, Einbinden von Unit-Tests, CVS bedienen, ...

• mehr als 100 Standardtasks vorhanden• einfach erweiterbar (custom tasks)

Ant (3)

Beispiel build.xml:

<?xml version="1.0"?><project name="Beispiel Buildfile“ basedir="."><target name="compile" description="alles kompilieren"> <javac srcdir="src" destdir="build"/></target></project>

Ant (4)

Ausgabe:

Buildfile: D:\prj\xp\build.xml

compile: [javac] Compiling 32 source files to D:\prj\xp\build

BUILD SUCCESSFULTotal time: 7 minutes

JUnit (1)

Was ist JUnit?• Java-basiertes Framework für automatisierte

Tests• JUnit API bildet Basis für speziellere Test-Tools• Integration in moderene IDEs vorhanden• Ant-Task für JUnit verfügbar• nicht geeignet für Tests von GUIs• XUnit-Frameworks für weitere Sprachen

verfügbar (CSUnit, utPLSQL)

JUnit (2)

Beispiel:

class Person { private String firstName; private String lastName;

public String getFullName() { return firstName + lastName; }}

JUnit (3)

Beispiel-Test:

import junit.framework.TestCase;

class TestPerson extends TextCase {

public void testGetFullName() { Person p = new Person(„Mia“, „Meyer“); assertEquals(„Mia Meyer“, p.getFullName()); }}

JUnit (4)

Integration in Ant:

<?xml version="1.0"?><project name="Ant JUnit demo" basedir="."><target name="junit">

<junit printsummary="on" showoutput="true" haltonerror="true">

<test name="TestPerson"/></junit>

</target></project>

JUnit (5)

Ausgabe:

Buildfile: D:\prj\xp\build.xmljunit: [junit] Running TestPerson [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec

BUILD FAILED: D:\prj\xp\build.xml:6: Test TestPerson failedTotal time: 266 milliseconds

Tools für XP

weitere Test-Tools:• HttpUnit (http://www.httpunit.org)

• Mock Objects (http://www.mockobjects.com)

• Cactus (http://jakarta.apache.org/cactus)

• JUnitPerf (http://clarkware.com/software/JUnitPerf.html)

Was macht XP schwierig? (1)

• Keine empirischen Untersuchungen zu Kent Becks Behauptungen über Kostenentwicklung

• Kollektive Code-Eigentümerschaft• Vernachlässigung der Tests bei Zeitknappheit• Tests nicht für jeden Fall vorhanden• wiederverwendbare Software ist kein Zufall• Soft Skills sind wesentliches Beitrag zum Erfolg

Was macht XP schwierig? (2)

• Idealvorstellung vom Team: flexibel, motiviert und kooperativ

• XP ist einfach in den Details, aber schwierig in der Ausführung

• Do the simplest thing that could possibly work• große Teams• Unternehmenskultur• Überstunden als Beweis für „Engagement für die

Firma“• lange Build-Zeiten, lange Qualitätschecks

Quellen„Extreme Programming explained“, Kent Beck, Addison-Wesley,

2000„Refactoring: Improving the Design of Existing Code“, Martin

Fowler, Addison-Wesley, 1999„Ant – The Definitive Guide“, Jesse Tilly & Eric M. Burke, O‘Reilly,

2002„Java Extreme Programming Cookbook“, Eric M. Burke & Brian M.

Coyner, O‘Reilly, 2003http://www.xprogramming.comhttp://www.extremeprogramming.orghttp://www.pairprogramming.comhttp://www.martinfowler.comhttp://www.refactoring.comhttp://c2.comhttp://www.junit.orghttp://jakarta.apache.org/ant