Patterns effektiv einsetzen
-
Upload
matthias-bohlen -
Category
Leadership & Management
-
view
48 -
download
0
Transcript of Patterns effektiv einsetzen
Patterns effektiv einsetzenAnatomie erfolgreicher Projekte
Vortrag auf der OOP 2007Matthias Bohlen <[email protected]>Unabhängiger Software-Architekt und Berater
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 2
Agenda
Erfolgreiche ProjekteNotwendiges HandwerkszeugPatterns in Software und in TeamsWas können Sie tun?Fragen und Antworten
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 3
Matthias Bohlen – das Profil
Unabhängiger BeraterArchitektur, Software-EngineeringModellgetriebene Software-Entwicklung, MDAObjekt- und Komponententechnologien
Dienstleistungen:Analyse, Design, Architektur
Project jump start
Technische Projektleitung
Therapie für Projekte in der Krise
Beratung
Schulung
Trainings
Coaching
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 4
Referenzen
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 5
Kunden
Kleine und große UnternehmenStarten Softwareprojekte
mit neuen oder unbekannten Technologienmit unklaren Methoden oder Prozessenmit engen Terminvorgabenmit sich schnell ändernden Anforderungenmanchmal ohne Architektur bzw. „Bauplan“
Insgesamt: hoher Beratungsbedarf
Die Expedition
Aufbruch ins Projekt – sind Sie richtig ausgerüstet?
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?
KarteKompassSonnenbrilleReserve-Kleidung
Essen & WasserHelm mit LampeErste-Hilfe-KitStreichhölzerMesser
Nur das unbedingt Nötige!Mehr ergibt sich von selbst!
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:
VisionGeschäftsidee PlanRisikolisteProblemliste
ArchitekturProduktwachstumMeilensteineChange RequestsBenutzer-Support
Schreiben Sie Ihre eigene "Packliste"!Mehr ergibt sich auch hier von selbst!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 9
Sie sind nicht die Ersten!
Viele Projekte vor Ihnen haben schon Erfahrung gesammeltLernen Sie aus diesen Projekten!Verzichten Sie auf Fehler (es sei denn, diese machen Ihnen Spaß)Also: Lesen Sie Patterns!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 10
Was tut ein Pattern?
Fasst Expertenwissen zusammenMacht dieses verständlichLöst wiederkehrende ProblemeSchafft Vokabular für LösungenBalanciert (widerstrebende) Kräfte ausArbeitet mit anderen Patterns zusammen
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 11
Was gibt es für Patterns?
Software Design (GoF)Organisations-PatternsBranchen-Patterns (Telekom, etc.)Pädagogik-Patternsund viele andere…
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 12
Was ist ein Pattern (1)?
EtwasSeine BeschreibungBeschreibung wie man "Etwas" erzeugtLösung eines wiederkehrenden Problems in einem Kontext
Diese ominöse "Definition" nützt Ihnen nur,wenn Sie schon wissen, was Patterns sind! ☺
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 bringtEine Methode, komplexes Verhalten aus einfachen Regeln zu erzeugenEin Weg, die Welt für Menschen angenehmer zu machen (nicht nur für Entwickler oder Lehrer…)
Klingt immer noch abstrakt, nicht wahr?
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 14
Elemente eines Patterns
ProblemKontext / UmständeKräfte (in der Ausgangssituation)LösungAnwendungsbeispielKonsequenzen und neuer Kontext
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 15
Beispiel: Verkehr
ProblemEntwerfen Sie eine Kreuzung zwischen zwei Landstraßen
KontextDänemark
Lösung: ?
KräfteWartungsarmLand ist billigStrom ist teuer zu transportierenVerkehr ist geringKeinen unnötigen Halt verursachen
Wie lautet dasselbe für die Schweiz bei starkem Verkehr?
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.
Na, ist ja ganz nett!
Aber was hat das mit einem Software-Projekt zu tun?
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 18
Beteiligte und Interessen
Null FehlerGute Dokumen-tationLeichte Änderbarkeit
Viele FeaturesBenutzer-freundlichkeitSchnelle, robuste Software
Interessante ArbeitErforschen neuer GebieteStressarmes ArbeitenLeben zu Hause
Alles im Plan!Keine Über-raschungenErfolgreiches Projekt
Kurze Realisie-rungszeitGeringe Kosten
Wartungs-personal
BenutzerEntwicklerChefsKunden
Nach Steve McConnell: Rapid Development
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 ErgebnisAlle Beteiligten sind zufrieden und möchten am liebsten sofort zusammen das nächste Projekt angehen!
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 entstehenMachen Sie aus jedem Beteiligten einen Gewinner!Patterns beschreiben, wie das geht…
Part 1:Projektmanagement
Erfolgreiche Projekte managen sich auf ganz bestimmte Weise…
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 ZeitplanFalsche Zahl von Leuten im Projekt
Warum ist das so schwierig?Studieren wir die Grundlagen
Was kann man tun?Zwei Patterns werden helfen
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 23
Projektdefinition: Kräfte (1)
Projektverlauf = f(s, u, t, q)s = Teamgrößeu = Funktionsumfangt = Zeit bzw. Terminq = QualitätVier Parameter, die sich gegenseitig nicht-linear und zeitverzögert beeinflussen!
Alptraum des Projektmanagers!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 24
Projektdefinition: Kräfte (3)
Umfang beeinflusst ZeitJe mehr Features zu realisieren sind, desto mehr Zeit wird benötigtKoppelnde Größe: "Schlagzahl" des Teams
Zeit beeinflusst QualitätZu knapp gesetzte Zeit: Fehler und WorkaroundsZu großzügig gesetzte Zeit: "Goldene Lösungen", die teuer, komplex oder überflüssig sind
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 25
Projektdefinition: Kräfte (4)
Qualität beeinflusst TeamgrößeGute Leute wollen gute Arbeit abliefernLeute werden kündigen, wenn die Qualität zu schlecht wird
Zeit beeinflusst TeamgrößeZeit zu knapp Entwickler gestresstLeute werden kündigen, wenn sie zu sehr gestresst werden
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 26
Projektdefinition: Kräfte (5)
Qualität beeinflusst ZeitJe schlechter die Qualität, desto höher der Zusatzaufwand bei ÄnderungenWorkarounds machen das Entwicklerteam langsamerBei schlechter Qualität wird mehr Zeit benötigt
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 27
Pattern: ZeitplanAushandelnProblem
Aushandeln eines Zeitplans, dem alle zustimmen können
KontextSoftwareprojekt, das gerade startetThema verstandenUmfang ungefähr definiert
KräfteKunde: Schnell realisieren,geringe KostenBenutzer: Viele FeaturesEntwickler: Stressarmes, interessantes Arbeiten
Nach Jim Coplien: "SizeTheSchedule"
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 28
Lösung: ZeitplanAushandeln
Qualität q ganz hoch haltenTermin(e) t festsetzenTeamgröße s als gegeben annehmen
Größe finden? Siehe nächstes Pattern!
Umfang u anpassenAlle paar Wochen:
Verhältnis u,s,t überdenken!
Schlagzahl des Teams ist eine guteRechengrundlage für u-Anpassung!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 29
ZeitplanAushandelnVoraussetzungen
Vertrauensverhältnis zwischen Kunde und EntwicklungsorganisationWichtigsten Teil des Umfangs in den ersten Iterationen realisieren
Kunde wird Umfangsanpassung eher für möglich halten als Vertröstung auf imaginären Folgetermin
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 30
Pattern: TeamWachsenLassenProblem
Ermitteln der richtigen Teamgröße
KontexteSoftwareprojekt, das gerade startetSoftwareprojekt, das schon eine Weile unterwegs ist
KräfteAnforderungen und Design anfangs unklar
Entwickler sitzen herum, also wenigLeute benötigt!Viele Features in kurzer Zeit mehrLeute benötigt!
Nach Jim Coplien: "SizeTheOrganization"
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 istProjekt kommt nicht schnell genug voran.
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 32
Zu großes TeamEin Team hat zwei Haupt-Aufgaben
Ergebnisse produzierenDie Kraft zur Produktion der Ergebnisse steigt linear mit der Mitgliederzahl
KommunizierenDer Aufwand für Kommunikation steigt quadratischmit der Mitgliederzahl
Effekt: Ab einer gewissen Größe kann das Team nicht mehr effizient arbeiten!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 33
Zu spätes WachstumBrooks: "Adding people to a late projectmakes it later!"
Neue Leute müssen sich einarbeitenverzö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
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 34
Lösung: TeamWachsenLassenStarten Sie mit ein paar Experten
Domänenwissen und AnalysemethodikArchitektur- und DesignwissenWenige, exzellente "Prototyper"
Nutzen Sie danach das Wissen um die voraussichtliche Projektgröße und planen Sie sofort Wachstumsphasen mit ein!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 35
Grenzen des Teamwachstums
V. A. Vyssotsky (Bell TelephoneLaboratories) 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
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 36
Hilfe! Neue Leute!
Sie haben TeamWachsenLassenerfolgreich angewendet.Jetzt kommen die eingeplantenneuen Leute!Die Experten müssen die Novizen anlernen und schaffen selbst nichts mehr! Was tun?
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 37
Pattern: NovizenLehrerProblem
Experten sollen Novizen unterrichten und trotzdem zum Projekt beitragen
KontextSoftwareteam, in Wachstum und Reorganisation begriffen
KräfteExperten allein sind zu wenig, um das System zu entwickelnProduktivitätszuwachs durch neue Leute erforderlichProduktiv.-Minderungdurch Unterricht ist aber schmerzhaft
Nach Jim Coplien: "DayCare"
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 38
Lösung zu NovizenLehrer
Halten Sie die Novizen rausaus dem ExpertenteamStellen Sie einen Experten für die Novizen ab und lassen Sie die anderen in Ruhe das System weiterentwickelnDas ist besser als Experten und Novizen gleichmäßig zu mischen!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 39
Woran liegt's?
Ein bisschen MathematikAnnahme: 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?
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 40
Experten getrennt von Novizen
X Experten schaffen normalerweise X*1 = X
N Novizenjeder schafft n mit n<<1, z.B. n=1/10
Ein Experte abgestellt für die NovizenTeam-Performance nur nochTP = (X-1) + N*n
Beispiel: X=5, N=10, n=0,1TP = (5-1)+10*0,1 = 5
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 jetztTP = X / ( N/X + 1 ) + N*n
Beispiel: X=5, N=10, n=0,1TP = 5 / (2+1) + 10*0,1 = 2,7
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 42
Sonstige Projektmanagement-Patterns
BenannteStabileBasenEntwickler kann Baseline selbst wählen, z.b. den Nightly Build oder das letzte ausführlich getestete Build
PrivateWeltEntwickler arbeitet in eigener Umgebungholt sich Änderungen der Kollegen explizit herein
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 43
Sonstige Projektmanagement-Patterns
AufgabeAufteilenbei Termin-Engpass eine Aufgabe in einen dringenden und einen weniger dringenden Teil aufteilendringenden Teil vor dem Termin, den Rest danach erledigen
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 44
Sonstige Projektmanagement-Patterns
TeamProAufgabeIn den besten Projekten kommen Krisen und sonstige Ablenkungen vorGründen Sie ein Sub-Team, das sich um die Krise kümmertLassen Sie das Haupt-Team ungehindert weiterarbeiten
Viele weitere Patterns von Jim Coplien:http://www.easycomp.org/cgi-bin/OrgPatterns?BookOutline
Part 2:Organisationsstile,organisches Wachstum
Angepasste Organisationen funktionieren besser…
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 46
Pattern: HolistischeVielfaltProblem
Entwicklung eines Subsystems benötigt viele Skills, jedoch sind Leute meist spezialisiert
KontextSoftwareprojektStark disjunktes Wissen bei den beteiligten Menschen
KräfteEin 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 mehrerenSpezialisten. Geben Sie dem Team Verantwortung für das fachliche Subsystem.
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 47
Pattern: SubsystemProSkillProblem
Software soll über längere Zeit wartbar bleiben, selbst wenn sich die Teamzusammen-setzung ändert
KontextLang laufendes ProjektDisjunkte Skills bei den beteiligten MenschenFluktuation im Team
KräfteFluktuation bringt VarianzVarianz kann Inkonsistenz im Code nach sich ziehenNeue Leute brauchen klar lesbaren Code, der ihre eigenes Vokabular verwendetNeue Leute müssen die Philosophie des alten Codes verstehen bzw. ablesen können
Lösung: Trennen Sie Subsysteme nach den Skillsder Mannschaft (GUI, Domänenmodell, Persistenz, Datenbankzugriff, usw.)
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!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 49
Pattern: Conway's LawProblem
Organisation finden, deren Kommunikations-wege die Architektur des Produktes unterstützen
KontextReiferes SoftwareprojektEntwicklerteamArchitekturteamReife, mitwachsendeArchitektur
KräfteSoftwarestruktur ändert sich innerhalb der ProjektlaufzeitAlte Teamstrukturen existieren weiterMismatch verursacht Reibung im Projekt
Lösung: Passen Sie die Organisation an!
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 TeamsPassen Sie deshalb bei sich ändernder Produktarchitektur die Struktur Ihrer Projektorganisation an!Das wird Reibungsverluste minimieren!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 51
Pattern: OrganisationUndOrtProblem
Kommunikationswege finden oder anpassen, wenn Teile des Projektes an verschiedenen Orten arbeiten
KontextSoftwareprojekt mit verteilten Teams
KräfteKommunikation über Ortsgrenzen hinweg ist schwieriger als direkte KommunikationTrotzdem notwendig, da gemeinsames Produkt zu erstellenOverhead minimieren
Lösung: Passen Sie architektonische und geographische Grenzen aneinander an!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 52
Produkt und Geographie (1)Es hat keinen Sinn, zusammenhängendeTeile 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"
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 selbenTeilprodukt P arbeiten, dann…
spalten Sie P in P1 und P2, schaffen dazwischen eine Schnittstelle und lassen P1 durch T1 und P2 durch T2 entwickeln oderlassen Sie ein Team umziehen, so dass es am selben Ort wie das andere Team sitzt!
Nach Jim Coplien: "OrganizationFollowsLocation"
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 54
Sonstige Organisationsstil-Patterns
WenigeRollenSindMehrProduzentenRollenSindWichtigerTeileUndHerrscheSchaffeKommunikationsPlätzeVerschiebeVerantwortungetc.
Part 3:Menschen und Code
Ein interessanter Zusammenhang…
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 56
Pattern: ArchitektImplementiertProblem
Dem Architekten Realitätsbezug und Autorität verschaffen
KontextSoftwareprojektArchitekten und Entwickler als explizite Rollen ausgeprägt
KräfteEntwickler treffen Einzelentscheidungen pro SubsystemAnerkannte, übergeordnete, strategische, technische Sicht und Leitung erforderlichMöglicher Konflikt
Lösung: Lassen Sie den Architektenteilweise mitentwickeln!
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"
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 58
ArchitektImplementiert (2)
Entwickler…entwerfen im Kleinenimplementieren, testen, kommunizierenwerden 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 jedochnicht auf den kritischen Pfad! ☺
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 59
Pattern: CodeBesitzProblem
Integrität bereits geschriebenen Codes bewahren
KontextSoftwareprojektStark disjunktesWissen im Entwicklerteam
KräfteGedanken 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.
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 60
CodeBesitz (1)
Entwickler arbeiten an getrennten Features der AnwendungFeatures benutzen jedoch dieselben ArchitekturkomponentenDaher werden Entwickler dazu tendieren, dieselben Komponenten modifizieren zu wollen
Nach Jim Coplien: "CodeOwnership"
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!
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 62
CodeBesitz (3)
KontraindikationEntwickler 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 "CollectiveOwnership": Wenn ich heute eine zu komplizierte Stelle einbaue, hast Du sie morgen schon rausfaktorisiert!
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 permanentFeature-Verantwortung bezieht sich auf eine Funktion der Anwendung und ist temporär!(so lange, bis das Feature realisiert ist)
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 64
Sonstige Code-PatternsArchitektSteuertProduktSchließeSieAlleEinRauchgefüllterRaumVarianzHinterSchnittstellePrivatesVersionierenLoseSchnittstellenetc…
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 65
Zusammenfassung
Patterns sind kondensiertes ErfahrungswissenPatterns haben einen Kontext, in dem sie angewendet werden sollenPatterns bieten eine anerkannte Lösung für eine häufig auftretende AufgabenstellungPatterns haben manchmal Kontraindikationen, so dass sie in einer bestimmten Situation nicht angewendet werden sollten
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 66
Mehr über Patterns erfahren?
Workshop "Patterns effektiv einsetzen"zusammen mit Dr. Gernot StarkeAnmelden?Email an: [email protected]
Buch „Organizational Patterns of Agile Software Development“Autor: James CoplienISBN: 0-13-146740-9
25. Januar 2007 © 2007 Matthias Bohlen, http://www.mbohlen.de/ 67
Ende des Vortrags
Danke für Ihre Aufmerksamkeit!
FRAGEN ?
Matthias Bohlen [email protected]
Tel. 0170 / 772 8545