Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
präsentiert
objectiF eXtrem programmieren Kann man objectiF eXtrem programmieren?
objectiF eXtrem <ul><li>Vorstellung </li></ul><ul><li>Einführung in XP </li></ul><ul><li>TheSourceCodeIsTheDesign </li></u...
Vorstellung <ul><li>SOFTWERFT (http://www.softwerft.de):  </li></ul><ul><li>Lösungen für professionelle Dienstleister </li...
eXtreme Programming <ul><li>Iterativer und adaptiver Softwareentwicklungsprozeß </li></ul><ul><li>Schöpfer: Kent Beck </li...
eXtreme Programming <ul><li>Einfaches Design </li></ul><ul><li>Coding Conventions </li></ul><ul><li>Collective Code Owners...
Einfaches Design <ul><li>Do the simplest thing that could possibly work. </li></ul><ul><li>Kurz gesagt: Entwickle niemals ...
Coding Conventions <ul><li>Bedingung für Collective Code Ownership.  </li></ul><ul><li>Bedingung für Teamarbeit, Produktiv...
Collective Code Ownership <ul><li>Jeder darf jede Codezeile in jedem Modul ändern. Ohne zu fragen. Das klingt viel revolut...
Pair Programming <ul><li>Laut Buch wird jede Zeile Produktionscode von zwei Leuten gemeinsam programmiert.  </li></ul><ul>...
Planning Game <ul><li>Planung der anstehenden Tasks zu Beginn der Iteration. </li></ul><ul><li>Festlegung der Prioritäten ...
Continuous Integration <ul><li>Der komplette Code des Projektes wird ständig (mindestens täglich) integriert und getestet....
Frequent Releases <ul><li>Es werden häufig (in jeder Iteration, also alle ca. 2-4 Wochen) Releases an den Kunden gegeben. ...
Kunde im Team <ul><li>Ein Mitarbeiter des Kunden ist Mitglied des Teams. </li></ul><ul><li>Er arbeitet im selben Raum, ste...
Gnadenloses Überarbeiten (Refactoring) <ul><li>Nach der Implementierung jedes neuen Features muß das Design insgesamt sowe...
Design durch Tests <ul><li>Code a little, test a little... Der Unit Test definiert die Schnittstelle einer Klasse.  </li><...
System Metapher <ul><li>Eine Metapher, die das System als ganzes treffend beschreibt.  </li></ul><ul><li>Meist schwer zu f...
40 Stunden Woche <ul><li>;-) </li></ul>
XP Integration I <ul><li>Einfaches Design </li></ul><ul><ul><li>Hart. </li></ul></ul><ul><ul><li>Architektur und Datenbank...
XP Integration II <ul><li>Planning Game </li></ul><ul><ul><li>Workflow und Modus müssen eingewöhnt werden. </li></ul></ul>...
XP Integration III <ul><li>Gnadenloses Überarbeiten (Refactoring) </li></ul><ul><ul><li>Hoher Spaßfaktor </li></ul></ul><u...
Integration Details <ul><li>12 Entwickler </li></ul><ul><li>Beginn der Einführungsphase im November </li></ul><ul><li>Reih...
Literatur <ul><li>http:// www .c2. com / cgi / wiki ? ExtremeProgrammingRoadmap </li></ul><ul><li>http://www.extremeprogra...
TheSourceCodeIsTheDesign <ul><li>Grobdesign in UML </li></ul><ul><ul><li>Wichtige, zentrale Klassen </li></ul></ul><ul><li...
Design durch Test oder UML? <ul><li>objectiF vs. xUnit </li></ul><ul><li>Vorteil objectiF </li></ul><ul><ul><li>Gut kommun...
Fragen <ul><li>? </li></ul><ul><li>? </li></ul><ul><li>? </li></ul>
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...
Nächste SlideShare
Wird geladen in …5
×

objectiF extrem

1.030 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Business
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

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

×