Softwareentwicklung von Kopf bis Fuß: [ein Buch zum Mitmachen und Verstehen]
Gespeichert in:
| Hauptverfasser: | , |
|---|---|
| Format: | Buch |
| Sprache: | German English |
| Veröffentlicht: |
Beijing ; Köln [u.a.]
O'Reilly
2008
|
| Schlagworte: | |
| Online-Zugang: | Inhaltsverzeichnis |
| Beschreibung: | XXXIII, 459 S. Ill., graph. Darst. |
| ISBN: | 9783897218628 3897218623 |
Internformat
MARC
| LEADER | 00000nam a2200000 c 4500 | ||
|---|---|---|---|
| 001 | BV023357376 | ||
| 003 | DE-604 | ||
| 005 | 20121018 | ||
| 007 | t | ||
| 008 | 080623s2008 ad|| |||| 00||| ger d | ||
| 015 | |a 08,N23,0049 |2 dnb | ||
| 015 | |a 08,A35,0054 |2 dnb | ||
| 016 | 7 | |a 988713659 |2 DE-101 | |
| 020 | |a 9783897218628 |c kart. : EUR 49.90, EUR 51.30 (AT), sfr 81.90 (freier Pr.) |9 978-3-89721-862-8 | ||
| 020 | |a 3897218623 |9 3-89721-862-3 | ||
| 035 | |a (OCoLC)244290755 | ||
| 035 | |a (DE-599)DNB988713659 | ||
| 040 | |a DE-604 |b ger |e rakddb | ||
| 041 | 1 | |a ger |h eng | |
| 049 | |a DE-1051 |a DE-859 |a DE-384 |a DE-M347 |a DE-858 |a DE-703 |a DE-20 |a DE-29T |a DE-Aug4 |a DE-1049 |a DE-860 |a DE-523 |a DE-634 |a DE-83 |a DE-573 |a DE-706 |a DE-861 |a DE-1102 |a DE-11 |a DE-526 |a DE-2070s |a DE-91G |a DE-1047 |a DE-863 | ||
| 082 | 0 | |a 005.12 |2 22/ger | |
| 084 | |a ST 230 |0 (DE-625)143617: |2 rvk | ||
| 084 | |a DAT 310f |2 stub | ||
| 084 | |a 004 |2 sdnb | ||
| 100 | 1 | |a Pilone, Dan |e Verfasser |4 aut | |
| 240 | 1 | 0 | |a Head first software development |
| 245 | 1 | 0 | |a Softwareentwicklung von Kopf bis Fuß |b [ein Buch zum Mitmachen und Verstehen] |c Dan Pilone ; Russ Miles |
| 264 | 1 | |a Beijing ; Köln [u.a.] |b O'Reilly |c 2008 | |
| 300 | |a XXXIII, 459 S. |b Ill., graph. Darst. | ||
| 336 | |b txt |2 rdacontent | ||
| 337 | |b n |2 rdamedia | ||
| 338 | |b nc |2 rdacarrier | ||
| 650 | 0 | 7 | |a Softwareentwicklung |0 (DE-588)4116522-6 |2 gnd |9 rswk-swf |
| 650 | 0 | 7 | |a Software Engineering |0 (DE-588)4116521-4 |2 gnd |9 rswk-swf |
| 689 | 0 | 0 | |a Softwareentwicklung |0 (DE-588)4116522-6 |D s |
| 689 | 0 | |5 DE-604 | |
| 689 | 1 | 0 | |a Software Engineering |0 (DE-588)4116521-4 |D s |
| 689 | 1 | |8 1\p |5 DE-604 | |
| 700 | 1 | |a Miles, Russ |e Verfasser |4 aut | |
| 856 | 4 | 2 | |m HBZ Datenaustausch |q application/pdf |u http://bvbr.bib-bvb.de:8991/F?func=service&doc_library=BVB01&local_base=BVB01&doc_number=016540896&sequence=000004&line_number=0001&func_code=DB_RECORDS&service_type=MEDIA |3 Inhaltsverzeichnis |
| 999 | |a oai:aleph.bib-bvb.de:BVB01-016540896 | ||
| 883 | 1 | |8 1\p |a cgwrk |d 20201028 |q DE-101 |u https://d-nb.info/provenance/plan#cgwrk | |
Datensatz im Suchindex
| DE-BY-863_location | 1340 |
|---|---|
| DE-BY-FWS_call_number | 1340/ST 230 P643st |
| DE-BY-FWS_katkey | 320750 |
| DE-BY-FWS_media_number | 083101273035 |
| _version_ | 1824553979616428032 |
| adam_text | Der Inhalt (im Überblick)
Einführung xxiü
1 Gute Software entwickeln: Den Kunden zufrieden stellen 1
2 Anforderungen sammeln: Wissen, was der Kunde will 29
3 Projektplanung: Mit Planung zum Erfolg 69
4 User-Stories und Tasks: Jetzt aber an die Arbeit 109
5 Gut genug-Design: Fertig werden — mit gutem Design 149
6 Versionskontrolle: Defensives Programmieren 177
6.5 Code erstellen: LascheA durch Schlitz Bstecken ... 219
7 Tests und kontinuierliche Integration: Damit nichts schiefgeht 235
8 Testgetriebenc Entwicklung: Ihren Code verantwortlich machen 275
9 Eine Iteration abschließen: Alles fügt sich zusammen 317
10 Die nächste Iteration: Es ist nicht kaputt.... reparieren Sie es trotzdem 349
11 Bugs: Bugs beheben wie ein Profi 383
12 Das wahre Leben: Ein Prozess fürs lieben 417
Der Inhalt (jetzt ausfiöirlich)
Einführung
Ihr entwicklungsfähiges Gehirn. Sie versuchen, etwas zu lernen,
und Ihr Hirn tut sein Bestes, damit das Gelernte nicht hängen bleibt. Es denkt
nämlich: »Wir sollten lieber ordentlich Platz für wichtigere Dinge lassen, z.B. für
das Wissen, welche Tiere einem gefährlich werden könnten, oder dass es eine
ganz schlechte Idee ist, nackt Snowboard zu fahren.« Tja, wie schaffen wir es
nun, Ihr Gehirn davon zu überzeugen, dass Ihr Leben davon abhängt, gute
Software entwickeln zu können?
Für wen ist dieses Buch? xxiv
Wir wissen, was Sie gerade denken. xxv
Metakognition: Nachdenken übers Denken xxvii
Und das können SIE tun, um sich Ihr Gehirn untenan zu machen xxix
Lies mich! xxx
Die Gutachter xxxii
Danksagungen xxxiii
Gute. Software entwickeln
IDen Kunden zufrieden stellen
Wenn Ihr Kunde unzufrieden ist, sind alle unzufrieden!
Jedes gute Stück Software fängt damit an,dass ein Kunde eine tolle Idee hat. Ihr Job
als Softwareentwickler ist es, diese Idee real werden zulassen. Aber aus einer vagen
Idee funktionsfähigen Code zu machen - Code, der den Kunden zufrieden stellt - ist
nicht ganz einfach. In diesem Kapitel werden Sie lernen, wie man verhindert, in der
Softwareentwicklung Schiffbruch zu erleiden: indem Sie genau die Software abliefern,
die benötigt wird, und zwar pünktlich und im Rahmen des Budgets. Jetzt schnappen
Sie sich mal Ihren Laptop, und dann ziehen wir los, um gute Software auf den Weg zu
bringen.
^^ Toms Touren gehen online 2
^^^^^ Die meisten Projekte starten mit zwei wichtigen Fragen 3
^^^ ^k Entwicklung nach dem »Big Bang«-Ansatz 4
^M I ¦ Wir spulen vor: zwei Wochen später 5
^^p M Big Bang-Entwicklung endet meist mit einer üblen BAUCHLANDUNG 6
^^^r Gute Software entwickeln heißt... 9
je| Das Ziel mit ITERATIONEN erreichen 10
Jede Iteration ist ein Mini-Projekt 14
Jede Iteration entspricht QUALITÄTS-Software 14
Der Kunde WIRD etwas verändern 20
Es ist Ihre Aufgabe, Anpassungen vorzunehmen 20
Da gibt es aber ein paar MÄCHTIGE Probleme ... 20
Iteration berücksichtigt Veränderungen automatisch (irgendwie jedenfalls) 22
Ihre Software ist erst fertig, wenn sie VERÖFFENTLICHT ist 25
Werkzeuge für Ihre Softwareentwickler-Kiste 26
Anforderungen sammeln
Wissen, was der Kunde will
2 Man kann nicht alles haben, was man will... der Kunde
allerdings SChon! Gute Softwareentwicklung liefert, was der Kunde haben will. In
diesem Kapitel geht es ausschließlich darum, wie wir von unseren Kunden erfahren können,
welche Anforderungen sie an die Software stellen. Sie werden lernen, wie User-Stories,
Brainstorming und das Planungsspiel Ihnen helfen, Ihrem Kunden in den Kopf zu sehen. Auf
diese Weise können Sie sicherstellen, am Ende des Projekts das angefertigt zu haben, was der
Kunde will... und nicht bloß eine armselige Imitation.
Ikarus Shuttle-Trips wird modernisiert 30
Sprechen Sie mit Ihrem Kunden, um an MEHR Informationen zu kommen 33
Blueskying — mit dem Kunden Wolken schieben 34
Aktuelles Angebot | Manchmal endet Blueskying so... 36
ra,i. anzeigen ^
„«h^i»,™: FieWebiiti „„, Shuttle toeben I Finden Sie heraus, wie sich die Leute KONKRET verhalten 37
Jesoeherndas aktuelle/ .^^u^,. EinSesushervon I
von Ikaros anzeigen, lksro» soll ein Shuttle borten I Ihre Anforderungen müssen KUNDENzentriert sein 39
können. |
Kundenfeedback zum Entwickeln von Anforderungen nutzen 41
™, Zosatzpaketb „„, Online bezahlen
„«n^w CbiiewriivvAr „^lb^, Einfeswhervon User-Stories definieren das WAS Ihres Projekts ...
Ikargs toll «in Spezlalpaket «iH ikaro* soll se[ne P«chu»a online 41 , , _ . , ,.,.,™-, ,„
Extras online heben können- bezahlen können, Abschätzungen definieren das WANN 43
^^^_^_^^ 1 Bürogespräch 47
~^» ¦ „„,. Hotel buehen mmtm
™! bIIiSIJ ~-*-1™ tS Tlllirv2L Spielen wir das Planungsspiel 48
^a^anr ,2 Ikaros soll «in «otslbwhenkon- ^ r
Raombafenomanisieri Machen Sie Annahmen den Prozess 51
^^^^m—m^m^SSSSSMM^^^^^^ m^ Fur eine User-Stor^ ist eine GROSSE Abschätzung eine SCHLECHTE
Abschätzung 54
Das Ziel heißt Konvergenz 57
Der Iterationszyklus von der Anforderung bis zur Abschätzung 60
Jetzt endlich sind Sie so weit und können das gesamte Projekt abschätzen ... 63
rrojektplsmmg
3 Mit Planung zum Erfolg
Jedes gute Stück Software beginnt mit einer soliden Planung.
In diesem Kapitel werden Sie lernen, wie Sie diese Planung erstellen. Sie werden lernen, mit
dem Kunden zusammenzuarbeiten, um Prioritäten für die Anforderungen festzulegen.
Sie werden Iterationen definieren, auf die Sie anschließend gemeinsam mit Ihrem Team
hinarbeiten können. Und schließlich werden Sie einen realisierbaren Projektplan ausarbeiten,
dem Sie sich mit Ihrem Team anvertrauen und dessen Durchführung Sie kontrollieren
können.Wenn Sie sich das erarbeitet haben, werden Sie genau wissen, wie Sie von den
Anforderungen zu Ihrer ersten lieferbaren Leistung kommen.
Kunden wollen ihre Software SOFORT! 70
Prioritäten festlegen - mit dem Kunden zusammen 73
Wir wissen, was in Meilenstein 1.0 hineinkommt (ja, vielleicht) 74
Wenn die Features nicht passen, überarbeiten Sie die Prioritäten 75
Manchmal bedeuten mehr Leute weniger Ertrag 77
Arbeiten Sie sich zu einem vernünftigen Meilenstein 1.0 vor 78
amwierer Folgendes... Bei Iterationen liegt die Würze in der Kürze 85
^_^-—¦ • --—n. Vergleich von Planung und Realität 87
X Klar, kein Problem, da kann ich )
(mich in zwei Tagen durchf rasen. / Velocity berücksichtigt Overhead m Ihren Abschätzungen 89
£ ° ^- ^~—S~^ Programmierer rechnen in UTOPISCHEN Tagen... 90
(Entwickler rechnen in REALEN Tagen ... 91
Wann dauert Ihre Iteration zu lange? 92
Befassen Sie sich mit dem Durchsatz, BEVOR Sie Iterationen einteilen 93 0
Zeit für eine Beurteilung 97 ei
Die große Tafel da an Ihrer Wand 100
rirklichkeit allerdings das hier; Wie Sic den Leutcn in Ihrcm Team das Leben vermiesen 103
y^ Auf dem Weg nach Hause schnapp ich
~ f mir einen Monster-Burger, bis 3 Uhr früh pro- ^—-^
User-Stories uncl Täsks
4 Jetzt aber an die Arbeit
Es wird Zeit, sich an die Arbeit zu machen. Mit user-stories erfassen
Sie, was entwickelt werden soll, und jetzt wird es Zeit, sich an die Arbeit zu machen und das
alles aufzuteilen, damit in diese User-Stories langsam Leben kommt. Im folgenden Kapitel
werden Sie lernen, wie Sie Ihre User-Stories in einzelne Tasks (Aufgaben) aufbrechen und
wie Task-Abschätzungen Ihnen helfen, Ihr Projekt von Anfang bis Ende zu überwachen. Sie
werden lernen, wie Sie Ihre Projekttafel aktualisieren und Tasks von »In Arbeit« nach »Erledigt«
verschieben, um am Ende eine vollständig fertiggestellte User-Story zu haben. Auf dem
Weg dahin werden Sie erfahren, wie Sie mit der unvermeidlichen unvorhergesehenen Arbeit
umgehen müssen, die Ihnen Ihr Kunde vorsetzen wird.
Dürfen wir vorstellen? - binHinUndWeg 110
Addieren sich Ihre Tasks zum richtigen Ergebnis? 113
Tragen Sie nur die Arbeit ab, die noch übrig ist 115
Hängen Sie Ihre Tasks an die Tafel 116
Fangen Sie an, an Ihren Tasks zu arbeiten 118
Ein Task ist erst dann IN ARBEIT, wenn er in Arbeit ist 119
Und wenn ich an zwei Sachen gleichzeitig arbeite? 120
Ihr erstes Stand-up-Meeting... 123
Ihr erSteS Stand-Up-MeetiWg ... Ta* l die »Date«-Klasse anlegen 124
Stand-up-Meeting: Tag 5, also Ende von Woche 1 ... 130
A1*rk ^ato ba«ke*peirte, Stand-up-Meeting: Tag 2, Woche2 136
an, KatWuths- S w **** ^H*! m S#L Wir unterbrechen dieses Kapitel... 140
ntw ^^ / Ungeplante Tasks müssen festgehalten werden 141
«Jv^T w 3 ^ä Unerwartete Tasks lassen Ihren Burndown-Verlauf ansteigen 143
^^ML ^HftK *3K. Durchsatz ist hilfreich, aber... 144
^^^^^^l ^^Bjj^P fl^^B Sie haben eine Menge zu tun... 146
^^^^^P ^B^V f ^^^^B ... aber Sie wissen GENAU, wo Sie stehen 147
^^M ^^Ek Bm f^
^^^K ^H^b ^^H| n. Durchsatz im Gespräch 148
Gut genug-Desxgn
5 Fertig werden - mit gutem Design
Gutes Design hilft Ihnen dabei, liefern zu können, im letzten Kapitel
sah es reichlich düster aus. Schlechtes Design hat allen das Leben schwer gemacht, und zur
Krönung des ganze Übels tauchte urplötzlich noch ein ungeplanterTask auf. In diesem Kapitel
werden wir uns ansehen, wie Sie mit Refactoring Ihr Design so umgestalten, dass Sie und Ihr
Team produktiver arbeiten können. Sie werden Prinzipien für gutes Design anwenden und
sich gleichzeitig davor hüten, ein »perfektes Design« anzustreben. Abschließend werden Sie mit
ungeplanten Tasks genau so umgehen wie mit der übrigen Arbeit in Ihrem Projekt, und dafür
werden Sie die große Projekttafel nutzen,die Sie an Ihrer Wand hängen haben.
binHinUndWeg steckt in ernsten Schwierigkeiten ... 150
Dieses Design verstößt gegen das Prinzip der einen Verantwortlichkeit 153
k Mehrere Verantwortlichkeiten im Design aufspüren 156
..¦. . ¦- - Von mehreren Verantwortlichkeiten zu einer Verantwortlichkeit übergehen 159
Hö m^M / Ihr DesiSn sollte dem SRP folge«: at)er ebenso dem DRY-Prinzip ... 160
.. / Das Post-Refactoring-Stand-up-Meeting... 164
V Ungeplante Tasks sind trotz allem immer noch Tasks 166
Die Demo ist selbst Teil Ihres Tasks 167
Wenn alles erledigt ist, ist die Iteration beendet 170
*•« In Arbeit Ev-Iecki ! « faazäesarQwi
I «I „
¦lUlf ^V Mtft ^
U Mb» Ä d,tit , ^O?
1 I v. ^-(»-a™ij. I ö . .—_^
^sJJ , - i °t T^ iö^ °
¦^ 7-^r^—^-jA - 7 1 lÄlt.
J— r ^ ; ^ iM-L-JÄ ri
_J ¦ N ^,ihi gdhi. ?e»ti3 K ^yieKdien
i j i _/^r^^^^^ s ™* i
r ~ —~~^ ~ I Abysihlosscr.
_ _—_—___^ ^^ - ^Jj^iii-
Versionskorttrolle
6 Defensives Programmieren
Sicherheit geht vor, wenn es darauf ankommt, wirklich
gute Software ZU Schreiben! Gute Software zu schreiben ist nicht einfach...
vor allem, wenn Sie sichergehen müssen, dass der Code funktioniert und dass das auch
so bleibt. Ein einziger Tippfehler reicht aus, eine ungünstige Entscheidung eines Kollegen
oder auch ein Festplatten-Crash, und Ihre gesamte Arbeit geht den Bach runter. Wenn Sie
aber mit Versionskontrolle arbeiten, können Sie dafür sorgen, dass Ihr Code immer sicher
in einem Repository aufbewahrt wird. Sie können Fehler rückgängig machen, und Sie
können Bugs beseitigen - sowohl in neuen als auch in älteren Versionen Ihrer Software.
Sie haben einen neuen Auftrag BcatBox Pro 178
r~„„„ cpj ^ Und jetzt die Arbeit am GUI... 182
ZZZ. ZZ. ¦ Und ein schneller Test... 183
£^- * - - r- B Führen Sie Ihrem Kunden die neue BeatBox vor 185
EÜÜ? - * ^T *7 ¦ Kommen wir zum Thema VERSIONSKONTROLLE 188
E5EI tU I ¦ Zuerst legen Sie Ihr Projekt an... 190
VBBBBBBBflHBBBM^HHPBi - ¦ ¦ anschließend können Sie Code ein- und auschecken 191
^^^^^ Die meisten Werkzeuge zur Versionskontrolle versuchen,
Beat OX Pro 1.0 Probleme für Sie zu lösen 192
Der Server versucht, Ihre Änderungen ZUSAMMENZUFÜHREN 193
Wenn Ihre Software die Änderungen nicht zusammenführen kann.
meldet sie einen Konflikt 194
mrnmMM ,,j Noch mehr Iterationen, noch mehr Stories... 198
™™~ . _ _ -HZ, ¦ Wir haben mehr als eine Version von unserer Software... 200
SU - - .,™~ ¦ Gute Commit-Kommcntarc machen es Ihnen leichter.
Z^T - - - « ZT I ältere Software zu finden 202
2J2 ~ ^ - ¦ Jetzt können Sie Version 1.0 auschecken 203
HSI WM^B (Notfall-)Stand-up-Meeting 204
VMHHSSMHSBBBMHHmh^P Geben Sie Ihren Versionen ein Tag 205
*^^^^^ Tags, Zweige und Trunks... au weia! 207
PeatPOX Pro l.X /crsion i .0 korrigieren ... diesmal aber wirklich! 208
Wir haben jetzt ZWEI Codestämme. 209
Wann man KEINEN Zweig anlegen sollte ... 212
#Zen oder die Kunst vom guten Verzweigen 212
Was Versionskontrollc macht... 214
Versionskontrolle kann nicht dafür sorgen, dass Ihr Code
wirklich funktioniert... 215
Werkzeuge für Ihre Softwareennvickler-Kiste 216
Code erstellen
. # Lasche A durch Schlitz B stecken ...
fc^ I m Es lohnt sich, sich an die Anweisungen zu halten ... vor allem
¦ p I *ß Wenn Sie Sie Selbst geschrieben haben. Versionskontrolle allein reicht
^*^ * S^ nicht aus, um Ihren Code permanent abzusichern. Sie müssen sich Gedanken darüber machen,
Ihren Code zu kompilieren und als vertriebsfertiges Softwarepaket aufzubereiten. Und vor
allen Dingen: Welche Klasse soll die Hauptklasse sein? Wie soll sie ausgeführt werden? In
diesem Kapitel lernen Sie, wie ein Build-Tool Ihnen ermöglicht, Ihre eigenen Anweisungen
für den Umgang mit Ihrem Quellcode zu schreiben.
Entwickler sind keine Gedankenleser 220
Ihr Projekt in einem Schritt erstellen 221
Ant: Ein Build-Tool für Java-Projekte 222
Projekte, Properties, Targets, Tasks 223
Gute Build-Skripten... 228
Gute Build-Skripten gehen über das Übliche HINAUS 230
Auch Ihr Build-Skript ist Code 232
Neuer Entwickler, Klappe, die zweite 233
Werkzeuge für Ihre Softwareentwickler-Kiste 234
Einzelteile ijrfes Build-frQzess Lau££ä}iiges
Projekte System
i »ilder oder /Cohs J . •
/ i«» Bespiel... J^fiT!
Tests und kprrt3nuierl!clie Integration
7 Damit nichts schiefgeht
Auch die besten Entwickler können den Build beschädigen.
Jeder hat es schon einmal gemacht. Sie sind sich sicher: Mein Code kompiliert. Sie haben ihn
immer wieder auf Ihrem System getestet und jetzt ins Repository eingepflegt. Aber auf dem
Weg zwischen Ihrem System und der schwarzen Kiste, die man Server nennt, muss jemand Ihren
Code geändert haben. Der arme Kerl, der den nächsten Check-out durchführt, wird einen harten
Tag damit verbringen, das in Ordnung zu bringen, was einmal funktionierender Code war. In
diesem Kapitel werden wir darüber reden, wie man ein Sicherheitsnetz aufbaut, um den Build
funktionsfähig und Sie selbst produktiv zu halten.
Schiefgehen tut es IMMER 236
Ihr System können Sie auf dreierlei Weise betrachten 238
Black-Box-Tests konzentrieren sich auf EINGABE und AUSGABE 239
Grey-Box-Tests bringen Sie NÄHER an den Code 240
White-Box-Tests nutzen Insiderwissen 243
ALLES in einem Schritt testen 248
Tests mit einem Test-Framework automatisieren 250
illJlfiMäw!* /jmISKUBK Führen Sie Ihre Tests mit dem Framework aus 251
iHjSpJf B ¦ CI im Griff mit CruiseControl 254
A, h iJ ^^^^^^^^ lÜH^^BK Tests stellen sicher, dass alles funktioniert... oder? 256
V ! U mHVI Den gesamten Code testen heißt, ALLE ZWEIGE zu testen 264
* * Blaclt-Box-Test ^lit einem Abdeckungsbericht prüfen, was abgedeckt wird 265
Eine gute Abdeckung zu erreichen ist nicht immer leicht... 267
Was Versionskontrollc macht... 270
Werkzeuge für Ihre Softwarcentwicklcr-Kiste 274
Testgetriebene Entwicklung
8 Ihren Code verantwortlich machen
Manchmal geht es nur darum, Erwartungen zu erfüllen. Guter
Code muss funktionieren, jeder weiß das. Aber woher wissen Sie, dass Ihr Code funktioniert?
Selbst mit Unit-Tests gibt es in großen Codemengen immer noch Bereiche, die ungetestet
bleiben. Aber was wäre, wenn Testen ein grundlegender Teil der Softwareentwicklung wäre?
Was ist, wenn Sie alles mit Blick auf Tests machen würden? In diesem Kapitel werden wir auf
dem aufbauen, was Sie über Versionskontrolle, Cl und automatisiertes Testen wissen, und alles zu
einer Umgebung zusammenbinden, in der Sie keine Angst vor dem Reparieren von Bugs, dem
Refactoring und soger der Neuimplementierung von Teilen Ihres Systems haben müssen.
Testen Sie ERST, nicht zum Schluss 276
Wir werden also ERST testen ... 277
Willkommen bei der testgesteuerten Entwicklung 277
Ihr erster Test... 278
... schlägt kläglich fehl 279
Machen Sie Ihre Tests GRÜN 280
Rot, grün, Refactoring... 281
Bei TDD LENKEN Tests Ihre Implementierung 286
Einen Task abzuschließen bedeutet, dass Sie alle erforderlichen
Tests haben und diese alle erfolgreich sind 28o
Gehen Sie weiter, wenn Ihr Test erfolgreich ist! 289
Einfachheit heißt, Abhängigkeiten zu vermeiden 29j
Schreiben Sie immer testbaren Code 294
Schauen Sie sich Ihren Entwurf an, wenn das Testen schwer wird 295
Das Strategy-Muster ermöglicht mehrere Implementierungen
eines Interface 296
Halten Sie Ihren Testcode bei Ihren Tests 299
Testen führt zu besserem Code 300
Mehr Tests bedeuten immer viel mehr Code 302
^^^ Strategy-Muster, lockere Bindung, Mock-Objekte... 303
^V Wir brauchen viele unterschiedliche, aber ähnliche Objekte 304
» Können wir nicht Objekte senerieren? 304
Ü Srüi: Ihr Tett ist erfolgreich. 1
I Ein Mock-Objekt vertritt echte Objekt 305
Refoctoring: Mit Verdopplungen. Hüisiich- J Mock-Objekte sind funktionierende Objektvertreter 306
ktiten, und aH*n Code usw. aufräumen. S . Qnn
^ l0,^^ Gute Software ist testbar 309
Es ist nicht immer leicht, grün zu sein ... 310
Ein Tag im Leben eines testgesteuerten Entwicklers 312
Werkzeuge für Ihre Softwareentwickler-Kiste 314
Eine Iteration abschließen
Alles fügt sich zusammen
9 Sie Sind fast fertig! Das Team hat hart gearbeitet, und jetzt fügt sich alles
zusammen. Ihre Aufgaben und User-Stories sind vollständig. Aber womit verbringen
Sie jetzt am besten den Tag, den Sie noch übrig haben? Wo können Sie Usability-Tests
einbauen? Können Sie eine weitere Refactoring- und Umarbeitungsrunde einbauen? Und
sicher treiben sich da noch eine Menge Fehler herum... wann werden die behoben? All das
ist Teil des Endes einer Iteration... machen wir uns also bereit, fertig zu werden.
Ihre Itcration ist fast abgeschlossen ... 318
... aber es gibt eine Menge, was Sie noch tun könnten 319
Systemtests sind NOTWENDIG ... 324
... aber WER führt sie durch? 325
Systemtests benötigen ein vollständiges System 326
Gute Systemtests erfordern ZWEI Iterationszyklen 327
Mehr Iterationen führen zu mehr Problemen 328
10 Kennzeichen effektiver Systemtests 333
Leben (und Sterben) eines Bugs 334
Sie haben also einen Bug gefunden ... 336
j——-^_______^ Anatomie eines Bug-Reports 337
/ , j. Sü^w^ ¦ - Aber es gibt eine Menge Dinge, die Sie noch tun KONNTEN... 338
/ ««te* / ^ ¦ Zeit für den Iterationsrückblick 342
/ ~~~ ~ 1 a ¦ Einige Fragen für den Iterationsrückblick 343
/ 20—--—.^ m ^ ne ALLGEMEINE Prioritätsliste zur Erledigung
/- ~- ^ t^j3—T-^ ¦ ZUSÄTZLICHER Dinge... 344
A^tsT~ —• . B Werkzeuge für Ihre Softwareentwickler-Kiste 346
xvii
Die nächste Iteration
Es ist nicht kaputt... reparieren Sie es trotzdem
I ä^ Alles läuft gut? Warten Sie ab, das kann sich schnell ändern ...
¦ B W Ihre Iteration ist wunderbar gelaufen, und Sie haben rechtzeitig funktionierende Software
ausgeliefert. Zeit für die nächste Iteration? Kein Problem, stimmt s? Leider nicht ganz. In der
Softwareentwicklung dreht sich alles um Veränderung, und der Schritt zur nächsten Iteration
bildet darin keine Ausnahme. In diesem Kapitel werden Sie lernen, wie Sie sich auf die nächste
Iteration vorbereiten. Sie müssen Ihre Tafel neu aufbauen und Ihre Stories und Annahmen
anpassen - und das auf Basis dessen, was der Kunde JETZT mW, nicht darauf, was er vor einem
Monat wollte.
Was ist funktionierende Software? 350
Sie müssen die nächste Iteration planen 352
Der Durchsatz trägt dem WAHREN LEBEN Rechnung 359
Es geht IMMER noch um den Kunden 360
Auch die Software eines anderen ist BLOSS Software 362
Kundenzustimmung? Prüfen! 365
Ihren Code testen 370
Houston, wir haben ein ernsthaftes Problem ... 371
Vertrauen Sie KEINEM 373
Sie ohne Ihren Prozess 378
Sie mit Ihrem Prozess 379
dicht Usei^SUfes )-, .. ,
IfzplatzwilMih 1 I
I - —- (! ¦
Bugs
1. Bugs beheben wie ein Profi
I Ihr Code, Ihre Verantwortung ... Ihr Bug, Ihr Ruf! Wenns hart wird,
¦ müssen Sie den Karren selbst aus dem Dreck ziehen. Bugs, egal ob sie in Ihrem Code stecken
oder bloß in Code, den Ihre Software nutzt, gehören in der Softwareentwicklung zu den
Gegebenheiten des Lebens. Und wie alles andere sollte sich auch das Verfahren, mit dem
Sie Bugs behandeln, in Ihren restlichen Prozess einfügen. Sie müssen Ihre Tafel vorbereiten,
Ihren Kunden auf dem Laufenden halten, zuverlässig einschätzen, wie viel Arbeit es ist,
die Bugs zu beheben, und Refactoring sowie Prefactoring einsetzen, um Bugs zu reparieren
und in der Zukunft zu vermeiden.
Neulich in Iteration 2 386
Zunächst müssen Sie mit dem Kunden reden 386
Priorität eins: Die Dinge erstellbar machen 392
Wir könnten den Code reparieren ... 394
... müssen aber die Funktionalität reparieren 395
Herausfinden, welche Funktionalität funktioniert 396
JETZT wissen Sie, was nicht funktioniert 399
Was würden Sie tun? 399
Spike-Test zum Abschätzen 400
Was sagen Ihnen die Ergebnisse der Spike-Tests? 402
Das Bauchgefühl Ihres Teams zählt 404
Geben Sie Ihrem Kunden die Bug-Fix-Abschätzung 406
Die Dinge sehen gut aus... 410
... und Sie schließen die Iteration erfolgreich ab! 411
UND der Kunde ist zufrieden 412
P^Pppww»*«!^,.. Werkzeuge für Ihre Softwareentwickler-Kiste 414
Das Waiifö Leihen
Ein Prozess fürs Leben
J * J Sie haben eine Menge über die Entwicklung von Software
¦ fJ gelernt. Aber bevor Sie jetzt anfangen, Burndown-Graphen in jedes Büro zu hängen, sollten
m^^* Sie noch erfahren, wie man mit den Eigenarten des jeweiligen Projekts verfährt - in seinen
eigenen Begriffen. Es gibt eine Menge Ähnlichkeiten und Erfahrungswerte, die Sie von einem
Projekt ins nächste übernehmen sollten, aber überall gibt es auch spezifische Dinge, auf die
Sie vorbereitet sein sollten. Jetzt ist es Zeit, einen Blick darauf zu werfen, was Sie an einem
bestimmten Projekt gelernt haben und wohin Sie sich als Nächstes wenden solten, um noch
mehr zu lernen.
-•— 1 Einen Softwareentwicklungsprozess fixieren 418
U~ Ein guter Prozess liefert gute Software aus 419
• £—;—3—1—*i
i—i- ~ | Förmliche Kleidung erforderlich... 424
— ¦ ** Einige zusätzliche Ressourcen... 426
—Ü- - 1 Mehr Wissen = bessere Prozesse 427
-.. — Werkzeuge für Ihre Softwareentwickler-Kiste 428
Weis üki£ Uelht
ADie Top Five der Themen
(die wir nicht behandelt haben)
Schon mal das Gefühl gehabt, dass irgendetwas fehlt? Das
kennen Wir ... Gerade als Sie dachten,Sie wären fertig ...taucht was Neues auf.Wir
konnten Sie einfach nicht entlassen, ohne noch ein paar Dinge zu erwähnen, die ins restliche
Buch einfach nicht mehr gepasst haben. Zumindest nicht, wenn Sie dieses Buch immer noch
mit sich herumtragen können möchten, ohne dazu einen Leiterwagen hinter sich herziehen zu
müssen. Werfen Sie also einen Blick auf die Dinge, die Ihnen (immer noch) fehlen könnten.
1. UML-Klassendiagramme 434
2. Sequenzdiagramme 43(
/^~ ci ~—-- -v I 3. User-Stories und Anwendungsfällc 438
*g==r ^ 4. System-Tests vs. Unit-Tests 440
^yscWmdijceit :mi 5. Refactoring 441
+ je-t^estWiwdißkei-tü -in-t fc
+ se^esdUmdikeitfgesfihwmdiakei-t = «ü :void Ä „J„^OM BßWU tZCrW 1
Techniken und Prinzipien
B Werkzeuge für den erfahrenen
Softwareentwickler
Haben Sie sich auch schon gewünscht, es gäbe all
diese tollen Werkzeuge und Techniken irgendwo an
einem Platz Versammelt? Nun, hier kommt eine Zusammenfassung
aller Entwicklungstechniken und -prinzipien, die wir in diesem Buch behandelt
haben. Schauen Sie sich alle noch einmal an und überprüfen Sie, ob Sie noch
wissen, was sie im Einzelnen bedeuten.Vielleicht können Sie sich diese Seiten auch
ausschneiden und damit Ihre Projekttafel garnieren, so dass sie jeder während Ihrer
täglichen Stand-up-Meetings sehen kann.
Entwicklungstechniken 444
Entwicklungsprinzipen 446
|
| adam_txt |
Der Inhalt (im Überblick)
Einführung xxiü
1 Gute Software entwickeln: Den Kunden zufrieden stellen 1
2 Anforderungen sammeln: Wissen, was der Kunde will 29
3 Projektplanung: Mit Planung zum Erfolg 69
4 User-Stories und Tasks: Jetzt aber an die Arbeit 109
5 Gut genug-Design: Fertig werden — mit gutem Design 149
6 Versionskontrolle: Defensives Programmieren 177
6.5 Code erstellen: LascheA durch Schlitz Bstecken . 219
7 Tests und kontinuierliche Integration: Damit nichts schiefgeht 235
8 Testgetriebenc Entwicklung: Ihren Code verantwortlich machen 275
9 Eine Iteration abschließen: Alles fügt sich zusammen 317
10 Die nächste Iteration: Es ist nicht kaputt. reparieren Sie es trotzdem 349
11 Bugs: Bugs beheben wie ein Profi 383
12 Das wahre Leben: Ein Prozess fürs lieben 417
Der Inhalt (jetzt ausfiöirlich)
Einführung
Ihr entwicklungsfähiges Gehirn. Sie versuchen, etwas zu lernen,
und Ihr Hirn tut sein Bestes, damit das Gelernte nicht hängen bleibt. Es denkt
nämlich: »Wir sollten lieber ordentlich Platz für wichtigere Dinge lassen, z.B. für
das Wissen, welche Tiere einem gefährlich werden könnten, oder dass es eine
ganz schlechte Idee ist, nackt Snowboard zu fahren.« Tja, wie schaffen wir es
nun, Ihr Gehirn davon zu überzeugen, dass Ihr Leben davon abhängt, gute
Software entwickeln zu können?
Für wen ist dieses Buch? xxiv
Wir wissen, was Sie gerade denken. xxv
Metakognition: Nachdenken übers Denken xxvii
Und das können SIE tun, um sich Ihr Gehirn untenan zu machen xxix
Lies mich! xxx
Die Gutachter xxxii
Danksagungen xxxiii
Gute. Software entwickeln
IDen Kunden zufrieden stellen
Wenn Ihr Kunde unzufrieden ist, sind alle unzufrieden!
Jedes gute Stück Software fängt damit an,dass ein Kunde eine tolle Idee hat. Ihr Job
als Softwareentwickler ist es, diese Idee real werden zulassen. Aber aus einer vagen
Idee funktionsfähigen Code zu machen - Code, der den Kunden zufrieden stellt - ist
nicht ganz einfach. In diesem Kapitel werden Sie lernen, wie man verhindert, in der
Softwareentwicklung Schiffbruch zu erleiden: indem Sie genau die Software abliefern,
die benötigt wird, und zwar pünktlich und im Rahmen des Budgets. Jetzt schnappen
Sie sich mal Ihren Laptop, und dann ziehen wir los, um gute Software auf den Weg zu
bringen.
^^ Toms Touren gehen online 2
^^^^^ Die meisten Projekte starten mit zwei wichtigen Fragen 3
^^^ ^k Entwicklung nach dem »Big Bang«-Ansatz 4
^M I ¦ Wir spulen vor: zwei Wochen später 5
^^p M Big Bang-Entwicklung endet meist mit einer üblen BAUCHLANDUNG 6
^^^r Gute Software entwickeln heißt. 9
je| Das Ziel mit ITERATIONEN erreichen 10
Jede Iteration ist ein Mini-Projekt 14
Jede Iteration entspricht QUALITÄTS-Software 14
Der Kunde WIRD etwas verändern 20
Es ist Ihre Aufgabe, Anpassungen vorzunehmen 20
Da gibt es aber ein paar MÄCHTIGE Probleme . 20
Iteration berücksichtigt Veränderungen automatisch (irgendwie jedenfalls) 22
Ihre Software ist erst fertig, wenn sie VERÖFFENTLICHT ist 25
Werkzeuge für Ihre Softwareentwickler-Kiste 26
Anforderungen sammeln
Wissen, was der Kunde will
2 Man kann nicht alles haben, was man will. der Kunde
allerdings SChon! Gute Softwareentwicklung liefert, was der Kunde haben will. In
diesem Kapitel geht es ausschließlich darum, wie wir von unseren Kunden erfahren können,
welche Anforderungen sie an die Software stellen. Sie werden lernen, wie User-Stories,
Brainstorming und das Planungsspiel Ihnen helfen, Ihrem Kunden in den Kopf zu sehen. Auf
diese Weise können Sie sicherstellen, am Ende des Projekts das angefertigt zu haben, was der
Kunde will. und nicht bloß eine armselige Imitation.
Ikarus Shuttle-Trips wird modernisiert 30
Sprechen Sie mit Ihrem Kunden, um an MEHR Informationen zu kommen 33
Blueskying — mit dem Kunden Wolken schieben 34
Aktuelles Angebot | Manchmal endet Blueskying so. 36
ra,i. anzeigen ^
„«h^i»,™: FieWebiiti „„, Shuttle toeben I Finden Sie heraus, wie sich die Leute KONKRET verhalten 37
Jesoeherndas aktuelle/ .^^u^,. EinSesushervon I
von Ikaros anzeigen, lksro» soll ein Shuttle borten I Ihre Anforderungen müssen KUNDENzentriert sein 39
können. |
Kundenfeedback zum Entwickeln von Anforderungen nutzen 41
™, Zosatzpaketb „„, Online bezahlen
„«n^w CbiiewriivvAr „^lb^, Einfeswhervon User-Stories definieren das WAS Ihres Projekts .
Ikargs toll «in Spezlalpaket «iH ikaro* soll se[ne P«chu»a online 41 , , _ . , ,.,.,™-, ,„
Extras online heben können- bezahlen können, Abschätzungen definieren das WANN 43
^^^_^_^^ 1 Bürogespräch 47
~^»""¦"""" „„,. Hotel buehen mmtm
™! bIIiSIJ ~-*-1™'tS'Tlllirv2L Spielen wir das Planungsspiel 48
^a^anr ,2 Ikaros soll «in «otslbwhenkon- ^ r
Raombafenomanisieri """' Machen Sie Annahmen den Prozess 51
^^^^m—m^m^SSSSSMM^^^^^^"m^ Fur eine User-Stor^' ist eine GROSSE Abschätzung eine SCHLECHTE
Abschätzung 54
Das Ziel heißt Konvergenz 57
Der Iterationszyklus von der Anforderung bis zur Abschätzung 60
Jetzt endlich sind Sie so weit und können das gesamte Projekt abschätzen . 63
rrojektplsmmg
3 Mit Planung zum Erfolg
Jedes gute Stück Software beginnt mit einer soliden Planung.
In diesem Kapitel werden Sie lernen, wie Sie diese Planung erstellen. Sie werden lernen, mit
dem Kunden zusammenzuarbeiten, um Prioritäten für die Anforderungen festzulegen.
Sie werden Iterationen definieren, auf die Sie anschließend gemeinsam mit Ihrem Team
hinarbeiten können. Und schließlich werden Sie einen realisierbaren Projektplan ausarbeiten,
dem Sie sich mit Ihrem Team anvertrauen und dessen Durchführung Sie kontrollieren
können.Wenn Sie sich das erarbeitet haben, werden Sie genau wissen, wie Sie von den
Anforderungen zu Ihrer ersten lieferbaren Leistung kommen.
Kunden wollen ihre Software SOFORT! 70
Prioritäten festlegen - mit dem Kunden zusammen 73
Wir wissen, was in Meilenstein 1.0 hineinkommt (ja, vielleicht) 74
Wenn die Features nicht passen, überarbeiten Sie die Prioritäten 75
Manchmal bedeuten mehr Leute weniger Ertrag 77
Arbeiten Sie sich zu einem vernünftigen Meilenstein 1.0 vor 78
amwierer Folgendes. Bei Iterationen liegt die Würze in der Kürze 85
^_^-—¦ ""•" ""--—n. Vergleich von Planung und Realität 87
X Klar, kein Problem, da kann ich )
(mich in zwei Tagen durchf rasen. / Velocity berücksichtigt Overhead m Ihren Abschätzungen 89
£ ° ^- ^~—S~^ Programmierer rechnen in UTOPISCHEN Tagen. 90
(Entwickler rechnen in REALEN Tagen . 91
Wann dauert Ihre Iteration zu lange? 92
Befassen Sie sich mit dem Durchsatz, BEVOR Sie Iterationen einteilen 93 0
Zeit für eine Beurteilung 97 ei
Die große Tafel da an Ihrer Wand 100
rirklichkeit allerdings das hier; Wie Sic den Leutcn in Ihrcm Team das Leben vermiesen 103
y^ Auf dem Weg nach Hause schnapp ich \
~ f mir einen Monster-Burger, bis 3 Uhr früh pro- ^—-^
User-Stories uncl Täsks
4 Jetzt aber an die Arbeit
Es wird Zeit, sich an die Arbeit zu machen. Mit user-stories erfassen
Sie, was entwickelt werden soll, und jetzt wird es Zeit, sich an die Arbeit zu machen und das
alles aufzuteilen, damit in diese User-Stories langsam Leben kommt. Im folgenden Kapitel
werden Sie lernen, wie Sie Ihre User-Stories in einzelne Tasks (Aufgaben) aufbrechen und
wie Task-Abschätzungen Ihnen helfen, Ihr Projekt von Anfang bis Ende zu überwachen. Sie
werden lernen, wie Sie Ihre Projekttafel aktualisieren und Tasks von »In Arbeit« nach »Erledigt«
verschieben, um am Ende eine vollständig fertiggestellte User-Story zu haben. Auf dem
Weg dahin werden Sie erfahren, wie Sie mit der unvermeidlichen unvorhergesehenen Arbeit
umgehen müssen, die Ihnen Ihr Kunde vorsetzen wird.
Dürfen wir vorstellen? - binHinUndWeg 110
Addieren sich Ihre Tasks zum richtigen Ergebnis? 113
Tragen Sie nur die Arbeit ab, die noch übrig ist 115
Hängen Sie Ihre Tasks an die Tafel 116
Fangen Sie an, an Ihren Tasks zu arbeiten 118
Ein Task ist erst dann IN ARBEIT, wenn er in Arbeit ist 119
Und wenn ich an zwei Sachen gleichzeitig arbeite? 120
Ihr erstes Stand-up-Meeting. 123
Ihr erSteS Stand-Up-MeetiWg . Ta* l die »Date«-Klasse anlegen 124
Stand-up-Meeting: Tag 5, also Ende von Woche 1 . 130
A1*rk' ^ato ba«ke*peirte, Stand-up-Meeting: Tag 2, Woche2 136
an, KatWuths- S w **** ^H*! m S#L Wir unterbrechen dieses Kapitel. 140
ntw ^^ / Ungeplante Tasks müssen festgehalten werden 141
«Jv^T w"3 ^ä Unerwartete Tasks lassen Ihren Burndown-Verlauf ansteigen 143
^^ML ^HftK *3K. Durchsatz ist hilfreich, aber. 144
^^^^^^l ^^Bjj^P fl^^B Sie haben eine Menge zu tun. 146
^^^^^P ^B^V f ^^^^B . aber Sie wissen GENAU, wo Sie stehen 147
^^M ^^Ek Bm f^\
^^^K ^H^b ^^H| n. Durchsatz im Gespräch 148
Gut genug-Desxgn
5 Fertig werden - mit gutem Design
Gutes Design hilft Ihnen dabei, liefern zu können, im letzten Kapitel
sah es reichlich düster aus. Schlechtes Design hat allen das Leben schwer gemacht, und zur
Krönung des ganze Übels tauchte urplötzlich noch ein ungeplanterTask auf. In diesem Kapitel
werden wir uns ansehen, wie Sie mit Refactoring Ihr Design so umgestalten, dass Sie und Ihr
Team produktiver arbeiten können. Sie werden Prinzipien für gutes Design anwenden und
sich gleichzeitig davor hüten, ein »perfektes Design« anzustreben. Abschließend werden Sie mit
ungeplanten Tasks genau so umgehen wie mit der übrigen Arbeit in Ihrem Projekt, und dafür
werden Sie die große Projekttafel nutzen,die Sie an Ihrer Wand hängen haben.
binHinUndWeg steckt in ernsten Schwierigkeiten . 150
Dieses Design verstößt gegen das Prinzip der einen Verantwortlichkeit 153
k Mehrere Verantwortlichkeiten im Design aufspüren 156
.¦.'.'¦-'-\ Von mehreren Verantwortlichkeiten zu einer Verantwortlichkeit übergehen 159
Hö m^M / Ihr DesiSn sollte dem SRP folge«: at)er ebenso dem DRY-Prinzip . 160
. / Das Post-Refactoring-Stand-up-Meeting. 164
V Ungeplante Tasks sind trotz allem immer noch Tasks 166
Die Demo ist selbst Teil Ihres Tasks 167
Wenn alles erledigt ist, ist die Iteration beendet 170
*•« In Arbeit Ev-Iecki ! « faazäesarQwi
I ' «I \ „
¦lUlf ' ^V Mtft ^\ \
\ U Mb» Ä d,tit , ^O?
" 1 I v. \^-(»-a™ij. I ö . .—_^
^sJJ , \ """"- i °t T^ iö^ °
¦^"7-^r^—^-jA ' - 7"1""""" lÄlt.
J— r ^ ; ^ iM-L-JÄ"ri'
_J ¦ " " N ^,ihi gdhi. ?e»ti3 K ^yieKdien
i j i _/^r^^^^^ s'™*" i
r ~" —~~^ ~ I Abysihlosscr.
_ _—_—_^ ^^ -""""^Jj^iii-
Versionskorttrolle
6 Defensives Programmieren
Sicherheit geht vor, wenn es darauf ankommt, wirklich
gute Software ZU Schreiben! Gute Software zu schreiben ist nicht einfach.
vor allem, wenn Sie sichergehen müssen, dass der Code funktioniert und dass das auch
so bleibt. Ein einziger Tippfehler reicht aus, eine ungünstige Entscheidung eines Kollegen
oder auch ein Festplatten-Crash, und Ihre gesamte Arbeit geht den Bach runter. Wenn Sie
aber mit Versionskontrolle arbeiten, können Sie dafür sorgen, dass Ihr Code immer sicher
in einem Repository aufbewahrt wird. Sie können Fehler rückgängig machen, und Sie
können Bugs beseitigen - sowohl in neuen als auch in älteren Versionen Ihrer Software.
Sie haben einen neuen Auftrag BcatBox Pro 178
r~„„„ cpj ^ Und jetzt die Arbeit am GUI. 182
ZZZ. ZZ. ¦ Und ein schneller Test. 183
£^- *" - - r- B Führen Sie Ihrem Kunden die neue BeatBox vor 185
EÜÜ? - ""' "*""^T"*7 ¦ Kommen wir zum Thema VERSIONSKONTROLLE 188
E5EI "" " tU I ¦ Zuerst legen Sie Ihr Projekt an. 190
VBBBBBBBflHBBBM^HHPBi - ¦ ¦ anschließend können Sie Code ein- und auschecken 191
^^^^^ Die meisten Werkzeuge zur Versionskontrolle versuchen,
Beat OX Pro 1.0 Probleme für Sie zu lösen 192
Der Server versucht, Ihre Änderungen ZUSAMMENZUFÜHREN 193
Wenn Ihre Software die Änderungen nicht zusammenführen kann.
meldet sie einen Konflikt 194
mrnmMM ,,j Noch mehr Iterationen, noch mehr Stories. 198
™™~" . _ _ -HZ, ¦ Wir haben mehr als eine Version von unserer Software. 200
SU ' - - .,™~ ¦ Gute Commit-Kommcntarc machen es Ihnen leichter.
Z^T" - - - '«"'ZT I ältere Software zu finden 202
2J2" ~"^"-' ¦ Jetzt können Sie Version 1.0 auschecken 203
HSI WM^B (Notfall-)Stand-up-Meeting 204
VMHHSSMHSBBBMHHmh^P Geben Sie Ihren Versionen ein Tag 205
*^^^^^ Tags, Zweige und Trunks. au weia! 207
PeatPOX Pro l.X \/crsion i .0 korrigieren . diesmal aber wirklich! 208
Wir haben jetzt ZWEI Codestämme. 209
Wann man KEINEN Zweig anlegen sollte . 212
#Zen oder die Kunst vom guten Verzweigen 212
Was Versionskontrollc macht. 214
Versionskontrolle kann nicht dafür sorgen, dass Ihr Code
wirklich funktioniert. 215
Werkzeuge für Ihre Softwareennvickler-Kiste 216
Code erstellen
. # Lasche A durch Schlitz B stecken .
fc^ I m Es lohnt sich, sich an die Anweisungen zu halten . vor allem
¦ p I *ß Wenn Sie Sie Selbst geschrieben haben. Versionskontrolle allein reicht
^*^ * S^ nicht aus, um Ihren Code permanent abzusichern. Sie müssen sich Gedanken darüber machen,
Ihren Code zu kompilieren und als vertriebsfertiges Softwarepaket aufzubereiten. Und vor
allen Dingen: Welche Klasse soll die Hauptklasse sein? Wie soll sie ausgeführt werden? In
diesem Kapitel lernen Sie, wie ein Build-Tool Ihnen ermöglicht, Ihre eigenen Anweisungen
für den Umgang mit Ihrem Quellcode zu schreiben.
Entwickler sind keine Gedankenleser 220
Ihr Projekt in einem Schritt erstellen 221
Ant: Ein Build-Tool für Java-Projekte 222
Projekte, Properties, Targets, Tasks 223
Gute Build-Skripten. 228
Gute Build-Skripten gehen über das Übliche HINAUS 230
Auch Ihr Build-Skript ist Code 232
Neuer Entwickler, Klappe, die zweite 233
Werkzeuge für Ihre Softwareentwickler-Kiste 234
Einzelteile ijrfes Build-frQzess Lau££ä}iiges
"Projekte System
i »ilder oder /Cohs J . •
/ i«» Bespiel. J^fiT!
Tests und kprrt3nuierl!clie Integration
7 Damit nichts schiefgeht
Auch die besten Entwickler können den Build beschädigen.
Jeder hat es schon einmal gemacht. Sie sind sich sicher: Mein Code kompiliert. Sie haben ihn
immer wieder auf Ihrem System getestet und jetzt ins Repository eingepflegt. Aber auf dem
Weg zwischen Ihrem System und der schwarzen Kiste, die man Server nennt, muss jemand Ihren
Code geändert haben. Der arme Kerl, der den nächsten Check-out durchführt, wird einen harten
Tag damit verbringen, das in Ordnung zu bringen, was einmal funktionierender Code war. In
diesem Kapitel werden wir darüber reden, wie man ein Sicherheitsnetz aufbaut, um den Build
funktionsfähig und Sie selbst produktiv zu halten.
Schiefgehen tut es IMMER 236
Ihr System können Sie auf dreierlei Weise betrachten 238
Black-Box-Tests konzentrieren sich auf EINGABE und AUSGABE 239
Grey-Box-Tests bringen Sie NÄHER an den Code 240
White-Box-Tests nutzen Insiderwissen 243
ALLES in einem Schritt testen 248
Tests mit einem Test-Framework automatisieren 250
'illJlfiMäw!* /jmISKUBK Führen Sie Ihre Tests mit dem Framework aus 251
iHjSpJf B ¦ CI im Griff mit CruiseControl 254
\A, \ h'iJ ^^^^^^^^ lÜH^^BK Tests stellen sicher, dass alles funktioniert. oder? 256
V\! U\ mHVI Den gesamten Code testen heißt, ALLE ZWEIGE zu testen 264
* * Blaclt-Box-Test ^lit einem Abdeckungsbericht prüfen, was abgedeckt wird 265
Eine gute Abdeckung zu erreichen ist nicht immer leicht. 267
Was Versionskontrollc macht. 270
Werkzeuge für Ihre Softwarcentwicklcr-Kiste 274
Testgetriebene Entwicklung
8 Ihren Code verantwortlich machen
Manchmal geht es nur darum, Erwartungen zu erfüllen. Guter
Code muss funktionieren, jeder weiß das. Aber woher wissen Sie, dass Ihr Code funktioniert?
Selbst mit Unit-Tests gibt es in großen Codemengen immer noch Bereiche, die ungetestet
bleiben. Aber was wäre, wenn Testen ein grundlegender Teil der Softwareentwicklung wäre?
Was ist, wenn Sie alles mit Blick auf Tests machen würden? In diesem Kapitel werden wir auf
dem aufbauen, was Sie über Versionskontrolle, Cl und automatisiertes Testen wissen, und alles zu
einer Umgebung zusammenbinden, in der Sie keine Angst vor dem Reparieren von Bugs, dem
Refactoring und soger der Neuimplementierung von Teilen Ihres Systems haben müssen.
Testen Sie ERST, nicht zum Schluss 276
Wir werden also ERST testen . 277
Willkommen bei der testgesteuerten Entwicklung 277
Ihr erster Test. 278
. schlägt kläglich fehl 279
Machen Sie Ihre Tests GRÜN 280
Rot, grün, Refactoring. 281
Bei TDD LENKEN Tests Ihre Implementierung 286
Einen Task abzuschließen bedeutet, dass Sie alle erforderlichen
Tests haben und diese alle erfolgreich sind 28o
Gehen Sie weiter, wenn Ihr Test erfolgreich ist! 289
Einfachheit heißt, Abhängigkeiten zu vermeiden 29j
Schreiben Sie immer testbaren Code 294
Schauen Sie sich Ihren Entwurf an, wenn das Testen schwer wird 295
Das Strategy-Muster ermöglicht mehrere Implementierungen
eines Interface 296
Halten Sie Ihren Testcode bei Ihren Tests 299
Testen führt zu besserem Code 300
Mehr Tests bedeuten immer viel mehr Code 302
^^^ Strategy-Muster, lockere Bindung, Mock-Objekte. 303
^V Wir brauchen viele unterschiedliche, aber ähnliche Objekte 304
» \ Können wir nicht Objekte senerieren? 304
Ü Srüi: Ihr Tett ist erfolgreich. 1
I Ein Mock-Objekt vertritt echte Objekt 305
Refoctoring: Mit Verdopplungen. Hüisiich- J Mock-Objekte sind funktionierende Objektvertreter 306
ktiten, und aH*n Code usw. aufräumen. S . Qnn
^ "l0,^^ Gute Software ist testbar 309
Es ist nicht immer leicht, grün zu sein . 310
Ein Tag im Leben eines testgesteuerten Entwicklers 312
Werkzeuge für Ihre Softwareentwickler-Kiste 314
Eine Iteration abschließen
Alles fügt sich zusammen
9 Sie Sind fast fertig! Das Team hat hart gearbeitet, und jetzt fügt sich alles
zusammen. Ihre Aufgaben und User-Stories sind vollständig. Aber womit verbringen
Sie jetzt am besten den Tag, den Sie noch übrig haben? Wo können Sie Usability-Tests
einbauen? Können Sie eine weitere Refactoring- und Umarbeitungsrunde einbauen? Und
sicher treiben sich da noch eine Menge Fehler herum. wann werden die behoben? All das
ist Teil des Endes einer Iteration. machen wir uns also bereit, fertig zu werden.
Ihre Itcration ist fast abgeschlossen . 318
. aber es gibt eine Menge, was Sie noch tun könnten 319
Systemtests sind NOTWENDIG . 324
. aber WER führt sie durch? 325
Systemtests benötigen ein vollständiges System 326
Gute Systemtests erfordern ZWEI Iterationszyklen 327
Mehr Iterationen führen zu mehr Problemen 328
10 Kennzeichen effektiver Systemtests 333
Leben (und Sterben) eines Bugs 334
Sie haben also einen Bug gefunden . 336
\ ' j——-^_^ Anatomie eines Bug-Reports 337
/ , j. Sü^w^' ¦ - Aber es gibt eine Menge Dinge, die Sie noch tun KONNTEN. 338
/ ««te* / \^ ¦ Zeit für den Iterationsrückblick 342
/ ~~~ ~ 1 a ¦ Einige Fragen für den Iterationsrückblick 343
\ / 20—--—.^ \\ m ^'ne ALLGEMEINE Prioritätsliste zur Erledigung
/- ~- ^ t^j3—T-^ ¦ ZUSÄTZLICHER Dinge. 344
' A^tsT~ —• . B Werkzeuge für Ihre Softwareentwickler-Kiste 346
xvii
Die nächste Iteration
Es ist nicht kaputt. reparieren Sie es trotzdem
I ä^ Alles läuft gut? Warten Sie ab, das kann sich schnell ändern .
¦ B W Ihre Iteration ist wunderbar gelaufen, und Sie haben rechtzeitig funktionierende Software
ausgeliefert. Zeit für die nächste Iteration? Kein Problem, stimmt's? Leider nicht ganz. In der
Softwareentwicklung dreht sich alles um Veränderung, und der Schritt zur nächsten Iteration
bildet darin keine Ausnahme. In diesem Kapitel werden Sie lernen, wie Sie sich auf die nächste
Iteration vorbereiten. Sie müssen Ihre Tafel neu aufbauen und Ihre Stories und Annahmen
anpassen - und das auf Basis dessen, was der Kunde JETZT mW, nicht darauf, was er vor einem
Monat wollte.
Was ist funktionierende Software? 350
Sie müssen die nächste Iteration planen 352
Der Durchsatz trägt dem WAHREN LEBEN Rechnung 359
Es geht IMMER noch um den Kunden 360
Auch die Software eines anderen ist BLOSS Software 362
Kundenzustimmung? Prüfen! 365
Ihren Code testen 370
Houston, wir haben ein ernsthaftes Problem . 371
Vertrauen Sie KEINEM 373
Sie ohne Ihren Prozess 378
Sie mit Ihrem Prozess 379
dicht Usei^SUfes )-, . ,
IfzplatzwilMih 1 I
I - —- (! '""'¦
Bugs
1. Bugs beheben wie ein Profi
I Ihr Code, Ihre Verantwortung . Ihr Bug, Ihr Ruf! Wenns hart wird,
¦ müssen Sie den Karren selbst aus dem Dreck ziehen. Bugs, egal ob sie in Ihrem Code stecken
oder bloß in Code, den Ihre Software nutzt, gehören in der Softwareentwicklung zu den
Gegebenheiten des Lebens. Und wie alles andere sollte sich auch das Verfahren, mit dem
Sie Bugs behandeln, in Ihren restlichen Prozess einfügen. Sie müssen Ihre Tafel vorbereiten,
Ihren Kunden auf dem Laufenden halten, zuverlässig einschätzen, wie viel Arbeit es ist,
die Bugs zu beheben, und Refactoring sowie Prefactoring einsetzen, um Bugs zu reparieren
und in der Zukunft zu vermeiden.
Neulich in Iteration 2 386
Zunächst müssen Sie mit dem Kunden reden 386
Priorität eins: Die Dinge erstellbar machen 392
Wir könnten den Code reparieren . 394
. müssen aber die Funktionalität reparieren 395
Herausfinden, welche Funktionalität funktioniert 396
JETZT wissen Sie, was nicht funktioniert 399
Was würden Sie tun? 399
Spike-Test zum Abschätzen 400
Was sagen Ihnen die Ergebnisse der Spike-Tests? 402
Das Bauchgefühl Ihres Teams zählt 404
Geben Sie Ihrem Kunden die Bug-Fix-Abschätzung 406
Die Dinge sehen gut aus. 410
. und Sie schließen die Iteration erfolgreich ab! 411
UND der Kunde ist zufrieden 412
P^Pppww»*«!^,. Werkzeuge für Ihre Softwareentwickler-Kiste 414
Das Waiifö Leihen
Ein Prozess fürs Leben
J * J Sie haben eine Menge über die Entwicklung von Software
¦ fJ gelernt. Aber bevor Sie jetzt anfangen, Burndown-Graphen in jedes Büro zu hängen, sollten
m^^* Sie noch erfahren, wie man mit den Eigenarten des jeweiligen Projekts verfährt - in seinen
eigenen Begriffen. Es gibt eine Menge Ähnlichkeiten und Erfahrungswerte, die Sie von einem
Projekt ins nächste übernehmen sollten, aber überall gibt es auch spezifische Dinge, auf die
Sie vorbereitet sein sollten. Jetzt ist es Zeit, einen Blick darauf zu werfen, was Sie an einem
bestimmten Projekt gelernt haben und wohin Sie sich als Nächstes wenden solten, um noch
mehr zu lernen.
-•— 1 Einen Softwareentwicklungsprozess fixieren 418
U~\ " Ein guter Prozess liefert gute Software aus 419
• £—;—3—1—*i
i—i- ~ | Förmliche Kleidung erforderlich. 424
— ¦ ** Einige zusätzliche Ressourcen. 426
—Ü-"-'1 Mehr Wissen = bessere Prozesse 427
-. — Werkzeuge für Ihre Softwareentwickler-Kiste 428
Weis üki£ Uelht
ADie Top Five der Themen
(die wir nicht behandelt haben)
Schon mal das Gefühl gehabt, dass irgendetwas fehlt? Das
kennen Wir . Gerade als Sie dachten,Sie wären fertig .taucht was Neues auf.Wir
konnten Sie einfach nicht entlassen, ohne noch ein paar Dinge zu erwähnen, die ins restliche
Buch einfach nicht mehr gepasst haben. Zumindest nicht, wenn Sie dieses Buch immer noch
mit sich herumtragen können möchten, ohne dazu einen Leiterwagen hinter sich herziehen zu
müssen. Werfen Sie also einen Blick auf die Dinge, die Ihnen (immer noch) fehlen könnten.
1. UML-Klassendiagramme 434
2. Sequenzdiagramme 43(
/^~ ci ~—-- -v I 3. User-Stories und Anwendungsfällc 438
*g==r '^" ' 4. System-Tests vs. Unit-Tests 440
^yscWmdijceit :mi 5. Refactoring 441
+ je-t^estWiwdißkei-tü -in-t fc
+ se^esdUmdikeitfgesfihwmdiakei-t = «ü :void Ä „J„^OM BßWU"tZCrW 1
Techniken und Prinzipien
B Werkzeuge für den erfahrenen
Softwareentwickler
Haben Sie sich auch schon gewünscht, es gäbe all
diese tollen Werkzeuge und Techniken irgendwo an
einem Platz Versammelt? Nun, hier kommt eine Zusammenfassung
aller Entwicklungstechniken und -prinzipien, die wir in diesem Buch behandelt
haben. Schauen Sie sich alle noch einmal an und überprüfen Sie, ob Sie noch
wissen, was sie im Einzelnen bedeuten.Vielleicht können Sie sich diese Seiten auch
ausschneiden und damit Ihre Projekttafel garnieren, so dass sie jeder während Ihrer
täglichen Stand-up-Meetings sehen kann.
Entwicklungstechniken 444
Entwicklungsprinzipen 446 |
| any_adam_object | 1 |
| any_adam_object_boolean | 1 |
| author | Pilone, Dan Miles, Russ |
| author_facet | Pilone, Dan Miles, Russ |
| author_role | aut aut |
| author_sort | Pilone, Dan |
| author_variant | d p dp r m rm |
| building | Verbundindex |
| bvnumber | BV023357376 |
| classification_rvk | ST 230 |
| classification_tum | DAT 310f |
| ctrlnum | (OCoLC)244290755 (DE-599)DNB988713659 |
| dewey-full | 005.12 |
| dewey-hundreds | 000 - Computer science, information, general works |
| dewey-ones | 005 - Computer programming, programs, data, security |
| dewey-raw | 005.12 |
| dewey-search | 005.12 |
| dewey-sort | 15.12 |
| dewey-tens | 000 - Computer science, information, general works |
| discipline | Informatik |
| discipline_str_mv | Informatik |
| format | Book |
| fullrecord | <?xml version="1.0" encoding="UTF-8"?><collection xmlns="http://www.loc.gov/MARC21/slim"><record><leader>02037nam a2200469 c 4500</leader><controlfield tag="001">BV023357376</controlfield><controlfield tag="003">DE-604</controlfield><controlfield tag="005">20121018 </controlfield><controlfield tag="007">t</controlfield><controlfield tag="008">080623s2008 ad|| |||| 00||| ger d</controlfield><datafield tag="015" ind1=" " ind2=" "><subfield code="a">08,N23,0049</subfield><subfield code="2">dnb</subfield></datafield><datafield tag="015" ind1=" " ind2=" "><subfield code="a">08,A35,0054</subfield><subfield code="2">dnb</subfield></datafield><datafield tag="016" ind1="7" ind2=" "><subfield code="a">988713659</subfield><subfield code="2">DE-101</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="a">9783897218628</subfield><subfield code="c">kart. : EUR 49.90, EUR 51.30 (AT), sfr 81.90 (freier Pr.)</subfield><subfield code="9">978-3-89721-862-8</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="a">3897218623</subfield><subfield code="9">3-89721-862-3</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(OCoLC)244290755</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(DE-599)DNB988713659</subfield></datafield><datafield tag="040" ind1=" " ind2=" "><subfield code="a">DE-604</subfield><subfield code="b">ger</subfield><subfield code="e">rakddb</subfield></datafield><datafield tag="041" ind1="1" ind2=" "><subfield code="a">ger</subfield><subfield code="h">eng</subfield></datafield><datafield tag="049" ind1=" " ind2=" "><subfield code="a">DE-1051</subfield><subfield code="a">DE-859</subfield><subfield code="a">DE-384</subfield><subfield code="a">DE-M347</subfield><subfield code="a">DE-858</subfield><subfield code="a">DE-703</subfield><subfield code="a">DE-20</subfield><subfield code="a">DE-29T</subfield><subfield code="a">DE-Aug4</subfield><subfield code="a">DE-1049</subfield><subfield code="a">DE-860</subfield><subfield code="a">DE-523</subfield><subfield code="a">DE-634</subfield><subfield code="a">DE-83</subfield><subfield code="a">DE-573</subfield><subfield code="a">DE-706</subfield><subfield code="a">DE-861</subfield><subfield code="a">DE-1102</subfield><subfield code="a">DE-11</subfield><subfield code="a">DE-526</subfield><subfield code="a">DE-2070s</subfield><subfield code="a">DE-91G</subfield><subfield code="a">DE-1047</subfield><subfield code="a">DE-863</subfield></datafield><datafield tag="082" ind1="0" ind2=" "><subfield code="a">005.12</subfield><subfield code="2">22/ger</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">ST 230</subfield><subfield code="0">(DE-625)143617:</subfield><subfield code="2">rvk</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">DAT 310f</subfield><subfield code="2">stub</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">004</subfield><subfield code="2">sdnb</subfield></datafield><datafield tag="100" ind1="1" ind2=" "><subfield code="a">Pilone, Dan</subfield><subfield code="e">Verfasser</subfield><subfield code="4">aut</subfield></datafield><datafield tag="240" ind1="1" ind2="0"><subfield code="a">Head first software development</subfield></datafield><datafield tag="245" ind1="1" ind2="0"><subfield code="a">Softwareentwicklung von Kopf bis Fuß</subfield><subfield code="b">[ein Buch zum Mitmachen und Verstehen]</subfield><subfield code="c">Dan Pilone ; Russ Miles</subfield></datafield><datafield tag="264" ind1=" " ind2="1"><subfield code="a">Beijing ; Köln [u.a.]</subfield><subfield code="b">O'Reilly</subfield><subfield code="c">2008</subfield></datafield><datafield tag="300" ind1=" " ind2=" "><subfield code="a">XXXIII, 459 S.</subfield><subfield code="b">Ill., graph. Darst.</subfield></datafield><datafield tag="336" ind1=" " ind2=" "><subfield code="b">txt</subfield><subfield code="2">rdacontent</subfield></datafield><datafield tag="337" ind1=" " ind2=" "><subfield code="b">n</subfield><subfield code="2">rdamedia</subfield></datafield><datafield tag="338" ind1=" " ind2=" "><subfield code="b">nc</subfield><subfield code="2">rdacarrier</subfield></datafield><datafield tag="650" ind1="0" ind2="7"><subfield code="a">Softwareentwicklung</subfield><subfield code="0">(DE-588)4116522-6</subfield><subfield code="2">gnd</subfield><subfield code="9">rswk-swf</subfield></datafield><datafield tag="650" ind1="0" ind2="7"><subfield code="a">Software Engineering</subfield><subfield code="0">(DE-588)4116521-4</subfield><subfield code="2">gnd</subfield><subfield code="9">rswk-swf</subfield></datafield><datafield tag="689" ind1="0" ind2="0"><subfield code="a">Softwareentwicklung</subfield><subfield code="0">(DE-588)4116522-6</subfield><subfield code="D">s</subfield></datafield><datafield tag="689" ind1="0" ind2=" "><subfield code="5">DE-604</subfield></datafield><datafield tag="689" ind1="1" ind2="0"><subfield code="a">Software Engineering</subfield><subfield code="0">(DE-588)4116521-4</subfield><subfield code="D">s</subfield></datafield><datafield tag="689" ind1="1" ind2=" "><subfield code="8">1\p</subfield><subfield code="5">DE-604</subfield></datafield><datafield tag="700" ind1="1" ind2=" "><subfield code="a">Miles, Russ</subfield><subfield code="e">Verfasser</subfield><subfield code="4">aut</subfield></datafield><datafield tag="856" ind1="4" ind2="2"><subfield code="m">HBZ Datenaustausch</subfield><subfield code="q">application/pdf</subfield><subfield code="u">http://bvbr.bib-bvb.de:8991/F?func=service&doc_library=BVB01&local_base=BVB01&doc_number=016540896&sequence=000004&line_number=0001&func_code=DB_RECORDS&service_type=MEDIA</subfield><subfield code="3">Inhaltsverzeichnis</subfield></datafield><datafield tag="999" ind1=" " ind2=" "><subfield code="a">oai:aleph.bib-bvb.de:BVB01-016540896</subfield></datafield><datafield tag="883" ind1="1" ind2=" "><subfield code="8">1\p</subfield><subfield code="a">cgwrk</subfield><subfield code="d">20201028</subfield><subfield code="q">DE-101</subfield><subfield code="u">https://d-nb.info/provenance/plan#cgwrk</subfield></datafield></record></collection> |
| id | DE-604.BV023357376 |
| illustrated | Illustrated |
| index_date | 2024-07-02T21:07:48Z |
| indexdate | 2025-02-20T06:44:29Z |
| institution | BVB |
| isbn | 9783897218628 3897218623 |
| language | German English |
| oai_aleph_id | oai:aleph.bib-bvb.de:BVB01-016540896 |
| oclc_num | 244290755 |
| open_access_boolean | |
| owner | DE-1051 DE-859 DE-384 DE-M347 DE-858 DE-703 DE-20 DE-29T DE-Aug4 DE-1049 DE-860 DE-523 DE-634 DE-83 DE-573 DE-706 DE-861 DE-1102 DE-11 DE-526 DE-2070s DE-91G DE-BY-TUM DE-1047 DE-863 DE-BY-FWS |
| owner_facet | DE-1051 DE-859 DE-384 DE-M347 DE-858 DE-703 DE-20 DE-29T DE-Aug4 DE-1049 DE-860 DE-523 DE-634 DE-83 DE-573 DE-706 DE-861 DE-1102 DE-11 DE-526 DE-2070s DE-91G DE-BY-TUM DE-1047 DE-863 DE-BY-FWS |
| physical | XXXIII, 459 S. Ill., graph. Darst. |
| publishDate | 2008 |
| publishDateSearch | 2008 |
| publishDateSort | 2008 |
| publisher | O'Reilly |
| record_format | marc |
| spellingShingle | Pilone, Dan Miles, Russ Softwareentwicklung von Kopf bis Fuß [ein Buch zum Mitmachen und Verstehen] Softwareentwicklung (DE-588)4116522-6 gnd Software Engineering (DE-588)4116521-4 gnd |
| subject_GND | (DE-588)4116522-6 (DE-588)4116521-4 |
| title | Softwareentwicklung von Kopf bis Fuß [ein Buch zum Mitmachen und Verstehen] |
| title_alt | Head first software development |
| title_auth | Softwareentwicklung von Kopf bis Fuß [ein Buch zum Mitmachen und Verstehen] |
| title_exact_search | Softwareentwicklung von Kopf bis Fuß [ein Buch zum Mitmachen und Verstehen] |
| title_exact_search_txtP | Softwareentwicklung von Kopf bis Fuß [ein Buch zum Mitmachen und Verstehen] |
| title_full | Softwareentwicklung von Kopf bis Fuß [ein Buch zum Mitmachen und Verstehen] Dan Pilone ; Russ Miles |
| title_fullStr | Softwareentwicklung von Kopf bis Fuß [ein Buch zum Mitmachen und Verstehen] Dan Pilone ; Russ Miles |
| title_full_unstemmed | Softwareentwicklung von Kopf bis Fuß [ein Buch zum Mitmachen und Verstehen] Dan Pilone ; Russ Miles |
| title_short | Softwareentwicklung von Kopf bis Fuß |
| title_sort | softwareentwicklung von kopf bis fuß ein buch zum mitmachen und verstehen |
| title_sub | [ein Buch zum Mitmachen und Verstehen] |
| topic | Softwareentwicklung (DE-588)4116522-6 gnd Software Engineering (DE-588)4116521-4 gnd |
| topic_facet | Softwareentwicklung Software Engineering |
| url | http://bvbr.bib-bvb.de:8991/F?func=service&doc_library=BVB01&local_base=BVB01&doc_number=016540896&sequence=000004&line_number=0001&func_code=DB_RECORDS&service_type=MEDIA |
| work_keys_str_mv | AT pilonedan headfirstsoftwaredevelopment AT milesruss headfirstsoftwaredevelopment AT pilonedan softwareentwicklungvonkopfbisfußeinbuchzummitmachenundverstehen AT milesruss softwareentwicklungvonkopfbisfußeinbuchzummitmachenundverstehen |
Inhaltsverzeichnis
THWS Würzburg Teilbibliothek SHL, Raum I.2.11
| Signatur: |
1340 ST 230 P643st |
|---|---|
| Exemplar 1 | ausleihbar Verfügbar Bestellen |