objectiF extrem

862 views
768 views

Published on

Held this presentation about my first XP project in May, 2001. Amazed by how much of it is still valid... :-)

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
862
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

objectiF extrem

  1. 1. präsentiert
  2. 2. objectiF eXtrem programmieren Kann man objectiF eXtrem programmieren?
  3. 3. objectiF eXtrem <ul><li>Vorstellung </li></ul><ul><li>Einführung in XP </li></ul><ul><li>TheSourceCodeIsTheDesign </li></ul><ul><li>Code Generierung </li></ul>
  4. 4. Vorstellung <ul><li>SOFTWERFT (http://www.softwerft.de): </li></ul><ul><li>Lösungen für professionelle Dienstleister </li></ul><ul><li>SOFT:TIME ZEITLEISTUNGSMANAGEMENT automatisiert das kaufmännische Management von Dienstleistungen: vom Vertragsmanagement über die Zeiterfassung und das Genehmigungsverfahren bis hin zur Leistungsabrechnung, Rechnungsstellung und Auswertung der erzielten Ergebnisse. </li></ul><ul><li>Olaf Lewitz: </li></ul><ul><li>Geschäftsführer, Head of IT & Development </li></ul>
  5. 5. eXtreme Programming <ul><li>Iterativer und adaptiver Softwareentwicklungsprozeß </li></ul><ul><li>Schöpfer: Kent Beck </li></ul><ul><ul><li>„ L istening, T esting, C oding, D esigning. That's all there is to software. Anyone who tells you different is selling something.“ </li></ul></ul><ul><li>Erstes Projekt: Chrysler-Lohnabrechnung (ChryslerComprehensiveCompensation) </li></ul><ul><li>Pragmatische positive Erfahrungen werden als extreme Praktiken zu einem Ganzen </li></ul>
  6. 6. eXtreme Programming <ul><li>Einfaches Design </li></ul><ul><li>Coding Conventions </li></ul><ul><li>Collective Code Ownership </li></ul><ul><li>Pair Programming </li></ul><ul><li>Planning Game </li></ul><ul><li>Continuous Integration </li></ul><ul><li>Frequent Releases </li></ul><ul><li>Kunde im Team </li></ul><ul><li>Gnadenloses Überarbeiten (Refactoring) </li></ul><ul><li>Design durch Tests </li></ul><ul><li>System Metapher </li></ul><ul><li>40 Stunden Woche </li></ul>
  7. 7. Einfaches Design <ul><li>Do the simplest thing that could possibly work. </li></ul><ul><li>Kurz gesagt: Entwickle niemals mehr, als für das im Moment anstehende Feature notwendig ist. </li></ul><ul><li>Daraus ergibt sich ein iterativ wachsendes Design, das mit den implementierten Funktionen und deren Anforderungen wächst, nicht mit den Phantasien der Entwickler. </li></ul><ul><li>Ausnahme: Datenbank-Layout, Architektur. </li></ul><ul><li>Bedingung: Refactoring. </li></ul><ul><li>Mandatorisch. </li></ul>
  8. 8. Coding Conventions <ul><li>Bedingung für Collective Code Ownership. </li></ul><ul><li>Bedingung für Teamarbeit, Produktivität und PragmaticProgramming. </li></ul><ul><li>Mehr als mandatorisch. </li></ul><ul><li>Durch Codegenerierung zu unterstützen. </li></ul><ul><li>Beispiele: </li></ul><ul><ul><li>Präfixe und Postfixe </li></ul></ul><ul><ul><li>Sprache der Bezeichner, Groß- und Kleinschreibung </li></ul></ul><ul><ul><li>Codelayout </li></ul></ul><ul><ul><li>Alles, auf was man sich einigt, sollte fixiert sein! </li></ul></ul>
  9. 9. Collective Code Ownership <ul><li>Jeder darf jede Codezeile in jedem Modul ändern. Ohne zu fragen. Das klingt viel revolutionärer, als es ist - vor allem für die Entwickler. </li></ul><ul><li>Natürlich hat jeder die volle Verantwortung für den von ihm geschriebenen Code - das Config-Management verrät ihn... </li></ul><ul><li>Bedingung für Refactoring. </li></ul><ul><li>Absolut mandatorisch. </li></ul><ul><li>Folge: Teamstolz statt Programmiererstolz. Funktioniert erstaunlich schnell. </li></ul>
  10. 10. Pair Programming <ul><li>Laut Buch wird jede Zeile Produktionscode von zwei Leuten gemeinsam programmiert. </li></ul><ul><li>Erstaunlich (?) produktiv, wenn‘s funktioniert. Die Charaktere müssen passen. </li></ul><ul><li>Vorteile: Gute Einarbeitung von neuen, wenig Know-How-Gefälle, wenige Bugs, gute Tests, gute Akzeptanz, deutlich gesteigerte Produktivität. </li></ul><ul><li>Nachteil: Domänen- und technisches Wissen müssen gleichmäßig verteilt sein. </li></ul><ul><li>Optional. </li></ul>
  11. 11. Planning Game <ul><li>Planung der anstehenden Tasks zu Beginn der Iteration. </li></ul><ul><li>Festlegung der Prioritäten durch Kunden. </li></ul><ul><li>Aufwandsschätzung durch Entwickler. </li></ul><ul><li>Idealerweise mit Karteikarten. </li></ul><ul><li>Macht XP aus. </li></ul>
  12. 12. Continuous Integration <ul><li>Der komplette Code des Projektes wird ständig (mindestens täglich) integriert und getestet. </li></ul><ul><li>Kaum zusätzlicher Overhead für die Integration von Komponenten. </li></ul><ul><li>Fehler treten sehr früh zutage, die Ursache ist leicht zu finden. </li></ul><ul><li>Vollständiger Test aller Teile des Systems. </li></ul><ul><li>Macht XP aus. </li></ul>
  13. 13. Frequent Releases <ul><li>Es werden häufig (in jeder Iteration, also alle ca. 2-4 Wochen) Releases an den Kunden gegeben. </li></ul><ul><li>Kurzfristiges Feedback. </li></ul><ul><li>Leichte Adaptierbarkeit von Änderungswünschen. </li></ul><ul><li>Wenig Entwicklung „in die falsche Richtung“. </li></ul><ul><li>Macht XP aus. </li></ul>
  14. 14. Kunde im Team <ul><li>Ein Mitarbeiter des Kunden ist Mitglied des Teams. </li></ul><ul><li>Er arbeitet im selben Raum, steht jederzeit für Fragen der Entwickler zur Verfügung. </li></ul><ul><li>Spezifikation erfolgt en detail während der Entwicklung mit dem Anwender. </li></ul><ul><li>Idealvorstellung, optional. </li></ul>
  15. 15. Gnadenloses Überarbeiten (Refactoring) <ul><li>Nach der Implementierung jedes neuen Features muß das Design insgesamt soweit wie möglich vereinfacht werden. </li></ul><ul><li>Danach!! Hervorragend behandelt durch Fowler. </li></ul><ul><li>Stichwort: Eingeschlagenes Fenster... </li></ul><ul><li>Absolut mandatorisch. </li></ul>
  16. 16. Design durch Tests <ul><li>Code a little, test a little... Der Unit Test definiert die Schnittstelle einer Klasse. </li></ul><ul><li>Anwendungsfälle werden mit Grenz- und Problemfällen formuliert und dann &quot;erfüllt&quot;. </li></ul><ul><li>Idealer Weise gibt es keine Zeile ungetesteten Code. </li></ul><ul><li>Problem: Datenbanken (Testdaten) </li></ul><ul><li>Mandatorisch. </li></ul>
  17. 17. System Metapher <ul><li>Eine Metapher, die das System als ganzes treffend beschreibt. </li></ul><ul><li>Meist schwer zu finden. </li></ul><ul><li>Optional. </li></ul>
  18. 18. 40 Stunden Woche <ul><li>;-) </li></ul>
  19. 19. XP Integration I <ul><li>Einfaches Design </li></ul><ul><ul><li>Hart. </li></ul></ul><ul><ul><li>Architektur und Datenbanklayout müssen stehen. </li></ul></ul><ul><ul><li>Frameworkentwicklung geht erstaunlich gut. </li></ul></ul><ul><li>Coding Conventions </li></ul><ul><ul><li>Bedingung: Kooperation und Pragmatismus. </li></ul></ul><ul><ul><li>Laufend erweitern! </li></ul></ul><ul><ul><li>Erbsenzähler im Team hilft! </li></ul></ul><ul><li>Collective Code Ownership </li></ul><ul><ul><li>Einfacher als es scheint, Teamerfolg zahlt sich schnell aus. </li></ul></ul><ul><ul><li>Unit Tests beachten! </li></ul></ul><ul><li>Pair Programming </li></ul><ul><ul><li>Charaktere müssen zueinander passen. </li></ul></ul>
  20. 20. XP Integration II <ul><li>Planning Game </li></ul><ul><ul><li>Workflow und Modus müssen eingewöhnt werden. </li></ul></ul><ul><ul><li>Zeitschätzungen üben und dokumentieren! </li></ul></ul><ul><li>Continuous Integration </li></ul><ul><ul><li>Automatisierung notwendig </li></ul></ul><ul><li>Frequent Releases </li></ul><ul><ul><li>Automatisierung notwendig </li></ul></ul><ul><li>Kunde im Team </li></ul><ul><ul><li>Nicht bei jedem Kunden möglich </li></ul></ul><ul><ul><li>Bei Standardsoftware durch Produktmanagement zu ersetzen. </li></ul></ul>
  21. 21. XP Integration III <ul><li>Gnadenloses Überarbeiten (Refactoring) </li></ul><ul><ul><li>Hoher Spaßfaktor </li></ul></ul><ul><ul><li>Man muß sich immer wieder die Zeit nehmen </li></ul></ul><ul><li>Design durch Tests </li></ul><ul><ul><li>Selbstdisziplin </li></ul></ul><ul><ul><li>Bugs gleich in den Test! </li></ul></ul><ul><li>System Metapher </li></ul><ul><ul><li>Ich habe noch keine gute gesehen. </li></ul></ul><ul><li>40 Stunden Woche </li></ul><ul><ul><li>Stellt sich wohl von selbst ein, wenn alles andere stimmt... </li></ul></ul>
  22. 22. Integration Details <ul><li>12 Entwickler </li></ul><ul><li>Beginn der Einführungsphase im November </li></ul><ul><li>Reihenfolge: </li></ul><ul><ul><li>Coding Conventions </li></ul></ul><ul><ul><li>Unit Test Framework </li></ul></ul><ul><ul><li>Iterationsplan und –workflow </li></ul></ul><ul><ul><li>Integrationsumgebung (Build Management) </li></ul></ul>
  23. 23. Literatur <ul><li>http:// www .c2. com / cgi / wiki ? ExtremeProgrammingRoadmap </li></ul><ul><li>http://www.extremeprogramming.org/ </li></ul><ul><li>http:// www . xprogramming . com / </li></ul><ul><li>Kent Beck, Extreme Programming Explained: Embrace Change. ISBN: 0201616416 (dt. 3827317096 ) </li></ul><ul><li>MartinFowler, Refactoring: Improving the Design of Existing Code. ISBN: 0201485672 (dt. 3827316308) </li></ul><ul><li>Andrew Hunt, David Thomas, The Pragmatic Programmer: From Journeyman to Master. ISBN: 020161622X </li></ul>
  24. 24. TheSourceCodeIsTheDesign <ul><li>Grobdesign in UML </li></ul><ul><ul><li>Wichtige, zentrale Klassen </li></ul></ul><ul><li>Schnittstellendesign im UnitTest </li></ul><ul><li>Klassendiagramme sind die Ausnahme </li></ul><ul><li>objectiF wird genutzt für </li></ul><ul><ul><li>Codegenerierung </li></ul></ul><ul><ul><li>Aktivitätsdiagramme (Workflowdefinition) </li></ul></ul><ul><ul><li>Sequenzdiagramme für komplexe Zusammenhänge </li></ul></ul>
  25. 25. Design durch Test oder UML? <ul><li>objectiF vs. xUnit </li></ul><ul><li>Vorteil objectiF </li></ul><ul><ul><li>Gut kommunizierbar an Nicht-Entwickler </li></ul></ul><ul><ul><li>Übersicht über Zusammenhänge </li></ul></ul><ul><ul><li>Dokumentation für Einsteiger </li></ul></ul><ul><li>Vorteil UnitTest </li></ul><ul><ul><li>Schnittstellen werden vom Benutzer aus entworfen </li></ul></ul><ul><ul><li>Erfolgserlebnis, wenn Tests erfüllt sind </li></ul></ul><ul><ul><li>Für jede Komponente existiert sofort eine Beispielanwendung </li></ul></ul><ul><ul><li>Qualitätssicherung passiert quasi vor der Entwicklung </li></ul></ul>
  26. 26. Fragen <ul><li>? </li></ul><ul><li>? </li></ul><ul><li>? </li></ul>
  27. 27. KONTAKT ohltec SOFTWERFT GMBH Notkestraße 7 D- 22607 Hamburg Fon: +49 (0)40 - 31 99 1 -0 Fax: +49 (0)40 - 31 99 1 –100 [email_address] www.softwerft.de e

×