Was ist XP? (1)

1
Software Design Patterns
Extreme Programming (XP)
2
Übersicht
Name Extreme Programming
auch bekannt als Agile Methodik zur Softwareentwicklung
Typ Organisatorisches Pattern

• entstanden im Smalltalk-Umfeld
• erstmals 1997 im C3-Projekt bei Chrysler
  eingesetzt
• erste Publikation 1999 von Kent Beck

3
Was verspricht XP?
Dem Programmierer
Dem Kunde

• 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

4
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

5
Was ist XP? (1) Überblick

• Die vier Grundwerte von XP
• Einfachheit (simplicity)
• Kommunikation (communication)
• Feedback
• Mut (courage)

6
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

7
Was ist XP? (3) - Einfachheit

• Kosten für Änderungen bei Projekten

8
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

9
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

10
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

11
Die XP-Praktiken (1)

• Zusammenfassung Die 12 XP-Praktiken
• Planungsspiel (planning game)
• kurze Releasezyklen
• Metapher
• einfaches Design
• Testen
• Refactoring

12
Die XP-Praktiken (2)

• Programmieren in Paaren (pair programming)
• gemeinsame Verantwortlichkeit
• fortlaufende Integration
• 40-Stunden-Woche
• Kunde Vor-Ort
• Programmierstandards

13
Die XP-Praktiken (3)

• Folgerung Alle Praktiken stützen sich
  gegenseitig

Planungsspiel
Kunde Vor-Ort
40-Stunden-Woche
Metapher
einfaches Design
Refactoring
kurze Releasezyklen
Programmieren in Paaren
Testen
Programmierstandards
gemeinsame Verantwortlichkeit
fortlaufende Integration
14
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

15
Refactoring (2)

• Beispiel Vor Refactoring
• class Person
• private String firstName
• public void setFirst(String s)
• this.firstName s

16
Refactoring (3)

• Beispiel bessere Namen für Argumente
• class Person
• private String firstName
• public void setFirst(String firstName)
• this.firstName firstName

17
Refactoring (4)

• Beispiel Änderung des Methodennamens
• class Person
• private String firstName
• public void setFirstName(String firstName)
• this.firstName firstName

18
Refactoring (5)

• Wie wird Refactoring durchgeführt?
• Sicherstellen, dass Unit-Test für die zu ändernde
  Funktion existert
• Änderungen durchführen
• Unit-Tests ausführen
• Schritte 2-4 wiederholen, bis Refactoring beendet

19
Refactoring (6)

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

20
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)

21
Ant (1)

• Wozu ein Build-System?
• konstantes Refactoring
• gemeinsame Verantwortung
• wechselnde Programmierpaare
• unterschiedliche Konfigurationen
• Bestandteil des Buildsystems Cruise Control
  (http//cruisecontrol.sourceforge.net)

22
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)

23
Ant (3)

• Beispiel build.xml
• lt?xml version"1.0"?gt
• ltproject name"Beispiel Buildfile
• basedir"."gt
• lttarget name"compile"
• description"alles kompilieren"gt
• ltjavac srcdir"src"
• destdir"build"/gt
• lt/targetgt
• lt/projectgt

24
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

25
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)

26
JUnit (2)

• Beispiel
• class Person
• private String firstName
• private String lastName
• public String getFullName()
• return firstName lastName

27
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())

28
JUnit (4)

• Integration in Ant
• lt?xml version"1.0"?gt
• ltproject name"Ant JUnit demo" basedir"."gt
• lttarget name"junit"gt
• ltjunit printsummary"on"
• showoutput"true"
• haltonerror"true"gt
• lttest name"TestPerson"/gt
• lt/junitgt
• lt/targetgt
• lt/projectgt

29
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.xml6
• Test TestPerson failed
• Total time 266 milliseconds

30
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)

31
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

32
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

33
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, 2003
• http//www.xprogramming.com
• http//www.extremeprogramming.org
• http//www.pairprogramming.com
• http//www.martinfowler.com
• http//www.refactoring.com
• http//c2.com
• http//www.junit.org
• http//jakarta.apache.org/ant