Contenu connexe Similaire à Patterns effektiv einsetzen (20) Plus de Matthias Bohlen (20) Patterns effektiv einsetzen2. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 2
Agenda
Erfolgreiche Projekte
Notwendiges Handwerkszeug
Patterns in Software und in Teams
Was können Sie tun?
Fragen und Antworten
3. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 3
Matthias Bohlen – das Profil
Unabhängiger Berater
Architektur, Software-Engineering
Modellgetriebene Software-Entwicklung, MDA
Objekt- und Komponententechnologien
Dienstleistungen:
Analyse, Design, Architektur
Project jump start
Technische Projektleitung
Therapie für Projekte in der Krise
Beratung
Schulung
Trainings
Coaching
4. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 4
Referenzen
5. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 5
Kunden
Kleine und große Unternehmen
Starten Softwareprojekte
mit neuen oder unbekannten Technologien
mit unklaren Methoden oder Prozessen
mit engen Terminvorgaben
mit sich schnell ändernden Anforderungen
manchmal ohne Architektur bzw. „Bauplan“
Insgesamt: hoher Beratungsbedarf
7. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 7
Aufbruch ins Ungewisse
Wenn Sie zu einer Wanderexpedition
aufbrechen, was packen Sie unbedingt ein?
Karte
Kompass
Sonnenbrille
Reserve-Kleidung
Essen & Wasser
Helm mit Lampe
Erste-Hilfe-Kit
Streichhölzer
Messer
Nur das unbedingt Nötige!
Mehr ergibt sich von selbst!
8. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 8
Dasselbe für Software…
Für ein Softwareprojekt gilt dasselbe!
Brechen Sie auf, das Nötige im Gepäck:
Vision
Geschäftsidee
Plan
Risikoliste
Problemliste
Architektur
Produktwachstum
Meilensteine
Change Requests
Benutzer-Support
Schreiben Sie Ihre eigene "Packliste"!
Mehr ergibt sich auch hier von selbst!
9. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 9
Sie sind nicht die Ersten!
Viele Projekte vor Ihnen haben schon
Erfahrung gesammelt
Lernen Sie aus diesen Projekten!
Verzichten Sie auf Fehler (es sei denn,
diese machen Ihnen Spaß)
Also: Lesen Sie Patterns!
10. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 10
Was tut ein Pattern?
Fasst Expertenwissen zusammen
Macht dieses verständlich
Löst wiederkehrende Probleme
Schafft Vokabular für Lösungen
Balanciert (widerstrebende) Kräfte aus
Arbeitet mit anderen Patterns zusammen
11. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 11
Was gibt es für Patterns?
Software Design (GoF)
Organisations-Patterns
Branchen-Patterns (Telekom, etc.)
Pädagogik-Patterns
und viele andere…
12. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 12
Was ist ein Pattern (1)?
Etwas
Seine Beschreibung
Beschreibung wie man "Etwas" erzeugt
Lösung eines wiederkehrenden Problems in
einem Kontext
Diese ominöse "Definition" nützt Ihnen nur,
wenn Sie schon wissen, was Patterns sind! ☺
13. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 13
Was ist ein Pattern (2)?
Beziehungen zwischen Komponenten eines
Systems, das eine Menge von
Anforderungen ins Gleichgewicht bringt
Eine Methode, komplexes Verhalten aus
einfachen Regeln zu erzeugen
Ein Weg, die Welt für Menschen
angenehmer zu machen (nicht nur für
Entwickler oder Lehrer…)
Klingt immer noch abstrakt, nicht wahr?
14. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 14
Elemente eines Patterns
Problem
Kontext / Umstände
Kräfte (in der Ausgangssituation)
Lösung
Anwendungsbeispiel
Konsequenzen und neuer Kontext
15. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 15
Beispiel: Verkehr
Problem
Entwerfen Sie eine
Kreuzung zwischen
zwei Landstraßen
Kontext
Dänemark
Lösung: ?
Kräfte
Wartungsarm
Land ist billig
Strom ist teuer zu
transportieren
Verkehr ist gering
Keinen unnötigen Halt
verursachen
Wie lautet dasselbe für die Schweiz
bei starkem Verkehr?
16. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 16
Was ein Pattern nicht ist!
Wenn es nur einen Weg gibt, etwas zu tun,
ist er kein Pattern (Kontext und Kräfte sind
wichtig!)
Wenn es die Kräfte nicht ins Gleichgewicht
bringt, ist es kein Pattern.
Wenn es keinen Expertenkonsens gibt,
dass die Lösung die beste ist, ist es kein
Pattern.
17. Na, ist ja ganz nett!
Aber was hat das mit einem Software-Projekt zu
tun?
18. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 18
Beteiligte und Interessen
Null Fehler
Gute
Dokumen-
tation
Leichte
Änderbarkeit
Viele Features
Benutzer-
freundlichkeit
Schnelle,
robuste
Software
Interessante
Arbeit
Erforschen
neuer Gebiete
Stressarmes
Arbeiten
Leben zu
Hause
Alles im Plan!
Keine Über-
raschungen
Erfolgreiches
Projekt
Kurze
Realisie-
rungszeit
Geringe
Kosten
Wartungs-
personal
BenutzerEntwicklerChefsKunden
Nach Steve McConnell: Rapid Development
19. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 19
Erfolgreiche Projekte
Wann ist ein Projekt erfolgreich?
Erfolg ist eine Kombination aus…
Das Projekt produziert ein werthaltiges Ergebnis
Alle Beteiligten sind zufrieden und möchten am
liebsten sofort zusammen das nächste Projekt
angehen!
20. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 20
Weg zum Erfolg
Balancieren Sie die Kräfte aus, die aus den
Interessen der Beteiligten entstehen
Machen Sie aus jedem Beteiligten einen
Gewinner!
Patterns beschreiben, wie das geht…
22. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 22
Projekte richtig aufsetzen
Die entscheidenden Fehler passieren am Anfang
eines Projektes bei der Definition
Zu eng gesetzter Zeitplan
Falsche Zahl von Leuten im Projekt
Warum ist das so schwierig?
Studieren wir die Grundlagen
Was kann man tun?
Zwei Patterns werden helfen
23. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 23
Projektdefinition: Kräfte (1)
Projektverlauf = f(s, u, t, q)
s = Teamgröße
u = Funktionsumfang
t = Zeit bzw. Termin
q = Qualität
Vier Parameter, die sich gegenseitig nicht-
linear und zeitverzögert beeinflussen!
Alptraum des Projektmanagers!
24. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 24
Projektdefinition: Kräfte (3)
Umfang beeinflusst Zeit
Je mehr Features zu realisieren sind, desto mehr Zeit
wird benötigt
Koppelnde Größe: "Schlagzahl" des Teams
Zeit beeinflusst Qualität
Zu knapp gesetzte Zeit: Fehler und Workarounds
Zu großzügig gesetzte Zeit: "Goldene Lösungen", die
teuer, komplex oder überflüssig sind
25. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 25
Projektdefinition: Kräfte (4)
Qualität beeinflusst Teamgröße
Gute Leute wollen gute Arbeit abliefern
Leute werden kündigen, wenn die Qualität zu
schlecht wird
Zeit beeinflusst Teamgröße
Zeit zu knapp Entwickler gestresst
Leute werden kündigen, wenn sie zu sehr
gestresst werden
26. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 26
Projektdefinition: Kräfte (5)
Qualität beeinflusst Zeit
Je schlechter die Qualität, desto höher der
Zusatzaufwand bei Änderungen
Workarounds machen das Entwicklerteam
langsamer
Bei schlechter Qualität wird mehr Zeit benötigt
27. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 27
Pattern: ZeitplanAushandeln
Problem
Aushandeln eines
Zeitplans, dem alle
zustimmen können
Kontext
Softwareprojekt, das
gerade startet
Thema verstanden
Umfang ungefähr
definiert
Kräfte
Kunde: Schnell
realisieren,
geringe Kosten
Benutzer: Viele Features
Entwickler: Stressarmes,
interessantes Arbeiten
Nach Jim Coplien: "SizeTheSchedule"
28. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 28
Lösung: ZeitplanAushandeln
Qualität q ganz hoch halten
Termin(e) t festsetzen
Teamgröße s als gegeben annehmen
Größe finden? Siehe nächstes Pattern!
Umfang u anpassen
Alle paar Wochen:
Verhältnis u,s,t überdenken!
Schlagzahl des Teams ist eine gute
Rechengrundlage für u-Anpassung!
29. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 29
ZeitplanAushandeln
Voraussetzungen
Vertrauensverhältnis zwischen Kunde und
Entwicklungsorganisation
Wichtigsten Teil des Umfangs in den ersten
Iterationen realisieren
Kunde wird Umfangsanpassung eher für
möglich halten als Vertröstung auf
imaginären Folgetermin
30. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 30
Pattern: TeamWachsenLassen
Problem
Ermitteln der richtigen
Teamgröße
Kontexte
Softwareprojekt, das
gerade startet
Softwareprojekt, das
schon eine Weile
unterwegs ist
Kräfte
Anforderungen und
Design anfangs unklar
Entwickler sitzen
herum, also wenig
Leute benötigt!
Viele Features in
kurzer Zeit mehr
Leute benötigt!
Nach Jim Coplien: "SizeTheOrganization"
31. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 31
Zu kleines Team
Kritische Masse wird nicht erreicht, die
zum Schreiben eines großen Systems
(> 25.000 LOC) notwendig ist
Projekt kommt nicht schnell genug voran.
32. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 32
Zu großes Team
Ein Team hat zwei Haupt-Aufgaben
Ergebnisse produzieren
Die Kraft zur Produktion der Ergebnisse steigt
linear mit der Mitgliederzahl
Kommunizieren
Der Aufwand für Kommunikation steigt quadratisch
mit der Mitgliederzahl
Effekt: Ab einer gewissen Größe kann das
Team nicht mehr effizient arbeiten!
33. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 33
Zu spätes Wachstum
Brooks: "Adding people to a late project
makes it later!"
Neue Leute müssen sich einarbeiten
verzögerte Steigerung der Arbeitskraft
Neue Leute beanspruchen erfahrene Leute
Produktivität sinkt vorübergehend ab! (siehe
nächstes Pattern)
Ein Projekt in Verzug gerät noch mehr in Verzug,
wenn Sie Leute hinzufügen!
Brooks, Frederick: The Mythical Man-Month
34. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 34
Lösung: TeamWachsenLassen
Starten Sie mit ein paar Experten
Domänenwissen und Analysemethodik
Architektur- und Designwissen
Wenige, exzellente "Prototyper"
Nutzen Sie danach das Wissen um die
voraussichtliche Projektgröße und planen
Sie sofort Wachstumsphasen mit ein!
35. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 35
Grenzen des Teamwachstums
V. A. Vyssotsky (Bell Telephone
Laboratories) schätzt, dass ein großes
Projekt ein Manpower-Wachstum von max.
30% pro Jahr halten kann – mehr stresst
und verhindert sogar den notwendigen
Aufbau informeller Strukturen und
Kommunikationswege!
Nach Frederick Brooks und Jim Coplien
36. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 36
Hilfe! Neue Leute!
Sie haben TeamWachsenLassen
erfolgreich angewendet.
Jetzt kommen die eingeplanten
neuen Leute!
Die Experten müssen die Novizen
anlernen und schaffen selbst nichts
mehr! Was tun?
37. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 37
Pattern: NovizenLehrer
Problem
Experten sollen
Novizen unterrichten
und trotzdem zum
Projekt beitragen
Kontext
Softwareteam, in
Wachstum und
Reorganisation
begriffen
Kräfte
Experten allein sind zu
wenig, um das System
zu entwickeln
Produktivitätszuwachs
durch neue Leute
erforderlich
Produktiv.-Minderung
durch Unterricht ist aber
schmerzhaft
Nach Jim Coplien: "DayCare"
38. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 38
Lösung zu NovizenLehrer
Halten Sie die Novizen raus
aus dem Expertenteam
Stellen Sie einen Experten für die Novizen
ab und lassen Sie die anderen in Ruhe das
System weiterentwickeln
Das ist besser als Experten und Novizen
gleichmäßig zu mischen!
39. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 39
Woran liegt's?
Ein bisschen Mathematik
Annahme: Ein Experte hat normalerweise eine
Performance von 1.
Unterrichtet er einen Novizen, so fällt seine
Produktivität auf ½, bei zwei Novizen auf 1/3,
bei dreien auf ¼, bei m auf 1/(m+1).
Wie sieht also die Team-Performance aus,
wenn Novizen hereinkommen?
40. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 40
Experten getrennt von Novizen
X Experten
schaffen normalerweise X*1 = X
N Novizen
jeder schafft n mit n<<1, z.B. n=1/10
Ein Experte abgestellt für die Novizen
Team-Performance nur noch
TP = (X-1) + N*n
Beispiel: X=5, N=10, n=0,1
TP = (5-1)+10*0,1 = 5
41. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 41
Experten gemischt mit Nov.
Die Performance jedes Experten geht
zurück auf 1/(m+1), wobei m die Anzahl
der Novizen pro Experte ist
also m = N / X
Team-Performance ist also jetzt
TP = X / ( N/X + 1 ) + N*n
Beispiel: X=5, N=10, n=0,1
TP = 5 / (2+1) + 10*0,1 = 2,7
42. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 42
Sonstige Projektmanagement-Patterns
BenannteStabileBasen
Entwickler kann Baseline selbst wählen, z.b. den
Nightly Build oder das letzte ausführlich
getestete Build
PrivateWelt
Entwickler arbeitet in eigener Umgebung
holt sich Änderungen der Kollegen explizit herein
43. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 43
Sonstige Projektmanagement-Patterns
AufgabeAufteilen
bei Termin-Engpass eine Aufgabe in einen
dringenden und einen weniger dringenden Teil
aufteilen
dringenden Teil vor dem Termin, den Rest
danach erledigen
44. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 44
Sonstige Projektmanagement-Patterns
TeamProAufgabe
In den besten Projekten kommen Krisen und
sonstige Ablenkungen vor
Gründen Sie ein Sub-Team, das sich um die
Krise kümmert
Lassen Sie das Haupt-Team ungehindert
weiterarbeiten
Viele weitere Patterns von Jim Coplien:
http://www.easycomp.org/cgi-bin/OrgPatterns?BookOutline
46. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 46
Pattern: HolistischeVielfalt
Problem
Entwicklung eines
Subsystems benötigt
viele Skills, jedoch sind
Leute meist spezialisiert
Kontext
Softwareprojekt
Stark disjunktes Wissen
bei den beteiligten
Menschen
Kräfte
Ein Einzelner hat nicht alle
Skills, die benötigt werden,
z.B. GUI-Design,
Persistenz, Security, usw.
Um ein fachlich und
technisch korrektes
Subsystem zu schreiben,
benötigt man jedoch alle
diese Skills.
Lösung: Formen Sie ein Team aus mehreren
Spezialisten. Geben Sie dem Team
Verantwortung für das fachliche
Subsystem.
47. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 47
Pattern: SubsystemProSkill
Problem
Software soll über
längere Zeit wartbar
bleiben, selbst wenn sich
die Teamzusammen-
setzung ändert
Kontext
Lang laufendes Projekt
Disjunkte Skills bei den
beteiligten Menschen
Fluktuation im Team
Kräfte
Fluktuation bringt Varianz
Varianz kann Inkonsistenz
im Code nach sich ziehen
Neue Leute brauchen klar
lesbaren Code, der ihre
eigenes Vokabular
verwendet
Neue Leute müssen die
Philosophie des alten Codes
verstehen bzw. ablesen
können
Lösung: Trennen Sie Subsysteme nach den Skills
der Mannschaft (GUI, Domänenmodell,
Persistenz, Datenbankzugriff, usw.)
48. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 48
Na, welches von beiden denn nun?
HolistischeVielfalt oder SubsystemProSkill?
Antwort: Nehmen Sie beide!
Wenn Sie SubsystemProSkill weglassen…
…bekommen Sie eine wilde Mischung aus GUI,
Domänenmodell, Persistenz, Remoting, usw. im
selben Code!
Wenn Sie HolistischeVielfalt weglassen…
…bekommen Sie ein Zimmer mit GUI-Leuten, eins
mit Domänenmodellierern, eins mit Persistenz-
Spezialisten usw. und entsprechend wenig
Kommunikation!
49. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 49
Pattern: Conway's Law
Problem
Organisation finden,
deren Kommunikations-
wege die Architektur des
Produktes unterstützen
Kontext
Reiferes Softwareprojekt
Entwicklerteam
Architekturteam
Reife, mitwachsende
Architektur
Kräfte
Softwarestruktur ändert
sich innerhalb der
Projektlaufzeit
Alte Teamstrukturen
existieren weiter
Mismatch verursacht
Reibung im Projekt
Lösung: Passen Sie die Organisation an!
50. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 50
Organisation versus Produkt
Die Struktur des Produkts definiert die
Struktur der Kommunikationswege in den
Teams
Passen Sie deshalb bei sich ändernder
Produktarchitektur die Struktur Ihrer
Projektorganisation an!
Das wird Reibungsverluste minimieren!
51. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 51
Pattern: OrganisationUndOrt
Problem
Kommunikationswege
finden oder anpassen,
wenn Teile des
Projektes an
verschiedenen Orten
arbeiten
Kontext
Softwareprojekt mit
verteilten Teams
Kräfte
Kommunikation über
Ortsgrenzen hinweg ist
schwieriger als direkte
Kommunikation
Trotzdem notwendig, da
gemeinsames Produkt zu
erstellen
Overhead minimieren
Lösung: Passen Sie architektonische und
geographische Grenzen aneinander an!
52. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 52
Produkt und Geographie (1)
Es hat keinen Sinn, zusammenhängende
Teile des Produktes an getrennten Orten
zu entwickeln (umgekehrt ist das kein
Problem!)
Der Kommunikationsaufwand wird Sie
auffressen, deshalb wird die
Kommunikation nicht stattfinden, und das
Produkt wird leiden!
Nach Jim Coplien:
"OrganizationFollowsLocation"
53. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 53
Produkt und Geographie (2)
Wenn zwei Teams T1 und T2 an
verschiedenen Orten am selben
Teilprodukt P arbeiten, dann…
spalten Sie P in P1 und P2, schaffen dazwischen
eine Schnittstelle und lassen P1 durch T1 und P2
durch T2 entwickeln oder
lassen Sie ein Team umziehen, so dass es am
selben Ort wie das andere Team sitzt!
Nach Jim Coplien:
"OrganizationFollowsLocation"
54. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 54
Sonstige Organisationsstil-Patterns
WenigeRollenSindMehr
ProduzentenRollenSindWichtiger
TeileUndHerrsche
SchaffeKommunikationsPlätze
VerschiebeVerantwortung
etc.
56. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 56
Pattern: ArchitektImplementiert
Problem
Dem Architekten
Realitätsbezug und
Autorität verschaffen
Kontext
Softwareprojekt
Architekten und
Entwickler als explizite
Rollen ausgeprägt
Kräfte
Entwickler treffen
Einzelentscheidungen
pro Subsystem
Anerkannte,
übergeordnete,
strategische, technische
Sicht und Leitung
erforderlich
Möglicher Konflikt
Lösung: Lassen Sie den Architekten
teilweise mitentwickeln!
57. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 57
ArchitektImplementiert (1)
Architekten…
designen, beraten, kommunizieren,
koordinieren, führen (ja, tatsächlich!)
brauchen jedoch auch tiefes Wissen über
Komponentenbeziehungen, Protokolle, APIs,
Performance, etc.
dürfen nicht im Elfenbeinturm entwerfen
Nach Jim Coplien:
"ArchitectAlsoImplements"
58. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 58
ArchitektImplementiert (2)
Entwickler…
entwerfen im Kleinen
implementieren, testen, kommunizieren
werden den Architekten nicht unbedingt
respektieren, wenn er sie nicht versteht oder
"über den Wolken schwebt"
Deshalb: Lassen Sie den Architekten
teilweise Code schreiben!
Achtung: Lassen Sie den Architekten jedoch
nicht auf den kritischen Pfad! ☺
59. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 59
Pattern: CodeBesitz
Problem
Integrität bereits
geschriebenen Codes
bewahren
Kontext
Softwareprojekt
Stark disjunktes
Wissen im
Entwicklerteam
Kräfte
Gedanken hinter dem
Code stehen nicht im
Code (Code basiert z.B.
auf kompliziertem
Framework)
Codepflege verlangt
informierten Entwickler
Lösung: Definieren Sie "Besitzer"
pro Codemodul.
60. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 60
CodeBesitz (1)
Entwickler arbeiten an getrennten Features
der Anwendung
Features benutzen jedoch dieselben
Architekturkomponenten
Daher werden Entwickler dazu tendieren,
dieselben Komponenten modifizieren zu
wollen
Nach Jim Coplien: "CodeOwnership"
61. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 61
CodeBesitz (2)
Gefahr:
Viele Köche verderben den Brei!
Modul wird u.U. inkonsistent
Bei einfachem Code und geteiltem Wissen im
Entwicklerteam
kein Problem!
Bei kompliziertem Code und individuellem, nicht
geteiltem Hintergrundwissen
besser nur ein Koch pro Modul!
62. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 62
CodeBesitz (3)
Kontraindikation
Entwickler ist so stolz auf seinen Code, dass er
ihn so toll schreibt, dass nur noch er selbst ihn
versteht
XP verlangt deshalb aus guten Grund "Collective
Ownership": Wenn ich heute eine zu
komplizierte Stelle einbaue, hast Du sie morgen
schon rausfaktorisiert!
63. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 63
CodeBesitz (4)
Achtung: CodeBesitz nicht mit Feature-
Verantwortung verwechseln!
CodeBesitz bezieht sich auf ein Modul und ist
permanent
Feature-Verantwortung bezieht sich auf eine
Funktion der Anwendung und ist temporär!
(so lange, bis das Feature realisiert ist)
64. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 64
Sonstige Code-Patterns
ArchitektSteuertProdukt
SchließeSieAlleEin
RauchgefüllterRaum
VarianzHinterSchnittstelle
PrivatesVersionieren
LoseSchnittstellen
etc…
65. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 65
Zusammenfassung
Patterns sind kondensiertes Erfahrungswissen
Patterns haben einen Kontext, in dem sie
angewendet werden sollen
Patterns bieten eine anerkannte Lösung für
eine häufig auftretende Aufgabenstellung
Patterns haben manchmal
Kontraindikationen, so dass sie in einer
bestimmten Situation nicht angewendet
werden sollten
66. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 66
Mehr über Patterns erfahren?
Workshop "Patterns effektiv einsetzen"
zusammen mit Dr. Gernot Starke
Anmelden?
Email an: mbohlen@mbohlen.de
Buch „Organizational Patterns of Agile
Software Development“
Autor: James Coplien
ISBN: 0-13-146740-9
67. 25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 67
Ende des Vortrags
Danke für Ihre
Aufmerksamkeit!
FRAGEN ?
Matthias Bohlen
mbohlen@mbohlen.de
Tel. 0170 / 772 8545