Software Design Patterns Extreme Programming (XP)

Übersicht entstanden im Smalltalk-Umfeld erstmals 1997 im C3-Projekt bei Chrysler eingesetzt erste Publikation 1999 von Kent Beck NameExtreme Programming auch bekannt alsAgile Methodik zur Softwareentwicklung TypOrganisatorisches 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 ProgrammiererDem 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

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 Metapher 40-Stunden-Woche gemeinsame Verantwortlichkeit Programmierstandards Planungsspiel fortlaufende Integration kurze Releasezyklen Refactoring einfaches Design Testen Programmieren 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 (

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 (

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: <project name="Beispiel Buildfile basedir="."> <target name="compile" description="alles kompilieren"> <javac srcdir="src" destdir="build"/>

Ant (4) Ausgabe: Buildfile: D:\prj\xp\build.xml compile: [javac] Compiling 32 source files to D:\prj\xp\build BUILD SUCCESSFUL Total 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: <junit printsummary="on" showoutput="true" haltonerror="true">

JUnit (5) Ausgabe: Buildfile: D:\prj\xp\build.xml junit: [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 failed Total time: 266 milliseconds

Tools für XP weitere Test-Tools: HttpUnit ( Mock Objects ( Cactus ( JUnitPerf (

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, OReilly, 2002 Java Extreme Programming Cookbook, Eric M. Burke & Brian M. Coyner, OReilly,