Software Design Patterns

1. Software Design Patterns Extreme Programming (XP)

2. Übersicht • 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/catalog/)

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

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: <?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>

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.xml:6: 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, O‘Reilly, 2002 „Java Extreme Programming Cookbook“, Eric M. Burke & Brian M. Coyner, O‘Reilly, 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