objectiF extrem

präsentiert

objectiF eXtrem objectiF eXtrem programmierenprogrammieren

Kann man objectiF eXtrem programmieren?

18.04.23 © ohltec SOFTWERFT GMBH 3

objectiF eXtremobjectiF eXtrem

Vorstellung Einführung in XP TheSourceCodeIsTheDesign Code Generierung


VorstellungVorstellung

SOFTWERFT (http://www.softwerft.de): Lösungen für professionelle Dienstleister

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.

Olaf Lewitz: Geschäftsführer, Head of IT & Development


eXtreme ProgrammingeXtreme Programming

Iterativer und adaptiver Softwareentwicklungsprozeß

Schöpfer: Kent Beck– „Listening, Testing, Coding, Designing. That's

all there is to software. Anyone who tells you different is selling something.“

Erstes Projekt: Chrysler-Lohnabrechnung (ChryslerComprehensiveCompensation)

Pragmatische positive Erfahrungen werden als extreme Praktiken zu einem Ganzen


eXtreme ProgrammingeXtreme Programming

Einfaches Design Coding Conventions Collective Code Ownership Pair Programming Planning Game Continuous Integration Frequent Releases Kunde im Team Gnadenloses Überarbeiten (Refactoring) Design durch Tests System Metapher 40 Stunden Woche


Einfaches DesignEinfaches Design

Do the simplest thing that could possibly work. Kurz gesagt: Entwickle niemals mehr, als für das

im Moment anstehende Feature notwendig ist. Daraus ergibt sich ein iterativ wachsendes

Design, das mit den implementierten Funktionen und deren Anforderungen wächst, nicht mit den Phantasien der Entwickler.

Ausnahme: Datenbank-Layout, Architektur. Bedingung: Refactoring. Mandatorisch.


Coding ConventionsCoding Conventions

Bedingung für Collective Code Ownership. Bedingung für Teamarbeit, Produktivität

und PragmaticProgramming. Mehr als mandatorisch. Durch Codegenerierung zu unterstützen. Beispiele:

– Präfixe und Postfixe– Sprache der Bezeichner, Groß- und

Kleinschreibung– Codelayout– Alles, auf was man sich einigt, sollte fixiert sein!


Collective Code OwnershipCollective Code Ownership

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.

Natürlich hat jeder die volle Verantwortung für den von ihm geschriebenen Code - das Config-Management verrät ihn...

Bedingung für Refactoring. Absolut mandatorisch. Folge: Teamstolz statt Programmiererstolz.

Funktioniert erstaunlich schnell.


Pair ProgrammingPair Programming

Laut Buch wird jede Zeile Produktionscode von zwei Leuten gemeinsam programmiert.

Erstaunlich (?) produktiv, wenn‘s funktioniert. Die Charaktere müssen passen.

Vorteile: Gute Einarbeitung von neuen, wenig Know-How-Gefälle, wenige Bugs, gute Tests, gute Akzeptanz, deutlich gesteigerte Produktivität.

Nachteil: Domänen- und technisches Wissen müssen gleichmäßig verteilt sein.

Optional.


Planning GamePlanning Game

Planung der anstehenden Tasks zu Beginn der Iteration.

Festlegung der Prioritäten durch Kunden. Aufwandsschätzung durch Entwickler. Idealerweise mit Karteikarten. Macht XP aus.


Continuous IntegrationContinuous Integration

Der komplette Code des Projektes wird ständig (mindestens täglich) integriert und getestet.

Kaum zusätzlicher Overhead für die Integration von Komponenten.

Fehler treten sehr früh zutage, die Ursache ist leicht zu finden.

Vollständiger Test aller Teile des Systems.

Macht XP aus.


Frequent ReleasesFrequent Releases

Es werden häufig (in jeder Iteration, also alle ca. 2-4 Wochen) Releases an den Kunden gegeben.

Kurzfristiges Feedback. Leichte Adaptierbarkeit von

Änderungswünschen. Wenig Entwicklung „in die falsche

Richtung“. Macht XP aus.


Kunde im TeamKunde im Team

Ein Mitarbeiter des Kunden ist Mitglied des Teams.

Er arbeitet im selben Raum, steht jederzeit für Fragen der Entwickler zur Verfügung.

Spezifikation erfolgt en detail während der Entwicklung mit dem Anwender.

Idealvorstellung, optional.


Gnadenloses Überarbeiten Gnadenloses Überarbeiten (Refactoring)(Refactoring)

Nach der Implementierung jedes neuen Features muß das Design insgesamt soweit wie möglich vereinfacht werden.

Danach!! Hervorragend behandelt durch Fowler.

Stichwort: Eingeschlagenes Fenster... Absolut mandatorisch.


Design durch TestsDesign durch Tests

Code a little, test a little... Der Unit Test definiert die Schnittstelle einer Klasse.

Anwendungsfälle werden mit Grenz- und Problemfällen formuliert und dann "erfüllt".

Idealer Weise gibt es keine Zeile ungetesteten Code.

Problem: Datenbanken (Testdaten) Mandatorisch.


System MetapherSystem Metapher

Eine Metapher, die das System als ganzes treffend beschreibt.

Meist schwer zu finden. Optional.


40 Stunden Woche40 Stunden Woche

;-)


XP Integration IXP Integration I

Einfaches Design– Hart.– Architektur und Datenbanklayout müssen stehen.– Frameworkentwicklung geht erstaunlich gut.

Coding Conventions– Bedingung: Kooperation und Pragmatismus.– Laufend erweitern!– Erbsenzähler im Team hilft!

Collective Code Ownership– Einfacher als es scheint, Teamerfolg zahlt sich schnell

aus.– Unit Tests beachten!

Pair Programming– Charaktere müssen zueinander passen.


XP Integration IIXP Integration II

Planning Game– Workflow und Modus müssen eingewöhnt

werden.– Zeitschätzungen üben und dokumentieren!

Continuous Integration– Automatisierung notwendig

Frequent Releases– Automatisierung notwendig

Kunde im Team– Nicht bei jedem Kunden möglich– Bei Standardsoftware durch

Produktmanagement zu ersetzen.


XP Integration IIIXP Integration III

Gnadenloses Überarbeiten (Refactoring)– Hoher Spaßfaktor– Man muß sich immer wieder die Zeit nehmen

Design durch Tests– Selbstdisziplin– Bugs gleich in den Test!

System Metapher– Ich habe noch keine gute gesehen.

40 Stunden Woche– Stellt sich wohl von selbst ein, wenn alles

andere stimmt...


Integration DetailsIntegration Details

12 Entwickler Beginn der Einführungsphase im

November Reihenfolge:

– Coding Conventions– Unit Test Framework– Iterationsplan und –workflow– Integrationsumgebung (Build Management)


LiteraturLiteratur

http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap http://www.extremeprogramming.org/ http://www.xprogramming.com/

Kent Beck, Extreme Programming Explained: Embrace Change. ISBN: 0201616416 (dt. 3827317096 )

MartinFowler, Refactoring: Improving the Design of Existing Code. ISBN: 0201485672 (dt. 3827316308)

Andrew Hunt, David Thomas, The Pragmatic Programmer: From Journeyman to Master. ISBN: 020161622X

http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap










http://www.xprogramming.com/








TheSourceCodeIsTheDesignTheSourceCodeIsTheDesign

Grobdesign in UML– Wichtige, zentrale Klassen

Schnittstellendesign im UnitTest Klassendiagramme sind die Ausnahme objectiF wird genutzt für

– Codegenerierung– Aktivitätsdiagramme (Workflowdefinition)– Sequenzdiagramme für komplexe

Zusammenhänge


Design durch Test oder UML?Design durch Test oder UML?

objectiF vs. xUnit Vorteil objectiF

– Gut kommunizierbar an Nicht-Entwickler– Übersicht über Zusammenhänge– Dokumentation für Einsteiger

Vorteil UnitTest– Schnittstellen werden vom Benutzer aus

entworfen– Erfolgserlebnis, wenn Tests erfüllt sind– Für jede Komponente existiert sofort eine

Beispielanwendung– Qualitätssicherung passiert quasi vor der

Entwicklung


FragenFragen

? ? ?

KONTAKT

ohltec SOFTWERFT GMBHNotkestraße 7D- 22607 HamburgFon: +49 (0)40 - 31 99 1 -0Fax: +49 (0)40 - 31 99 1 –100

[email protected]

Business

objectiF extrem