Feathers Effektives Arbeiten mit Legacy Code

Refactoring und Testen bestehender Software
1., 2011
ISBN: 978-3-95845-902-1
Verlag: mitp Verlags GmbH & Co.KG
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 432 Seiten

Reihe: mitp Professional

Legacy Code steht für Software ohne Tests und einen großen Haufen chaotischer Code, der irgendwie funktioniert, aber keiner weiß wieso. Fast jede Firma arbeitet mit veraltetem Code, der nicht mehr gut läuft oder Performance-Probleme mit sich bringt. Michael Feathers zeigt Software-Entwicklern in diesem Buch, wie sich aus altem Code mehr Performance und Zuverlässigkeit herausholen lässt und wie dieser besser handhabbar wird. Der Leser lernt, wie Software so verändert und Features hinzugefügt werden, dass sie dadurch nicht schlechter wird und wie man Tests schreibt, die vor neuen Problemen schützen. Die Techniken sind für jede Programmiersprache anwendbar, die Beispiele im Buch sind in Java, C++, C und C#.

Michael C. Feathers arbeitet bei Object Mentor Inc. und gibt zahlreiche Schulungen für Refactoring, Objektorientiertes Design uvm.

Zielgruppe

Software-Entwickler

Autoren/Hrsg.

Feathers, Michael C.

Inhaltsverzeichnis

1;Cover;1
2;Titel;3
3;Impressum;4
4;Inhaltsverzeichnis;7
5;Vorwort;13
6;Geleitwort;15
7;Danksagungen;21
8;Einführung - Wie man dieses Buch lesen sollte;23
9;Teil I: Wie Wandel funktioniert;25
9.1;Kapitel 1: Software ändern;27
9.1.1;1.1 Vier Gründe, Software zu ändern;27
9.1.2;1.2 Riskante Änderungen;31
9.2;Kapitel 2: Mit Feedback arbeiten;33
9.2.1;2.1 Was sind Unit-Tests?;36
9.2.2;2.2 Higher-Level-Tests;39
9.2.3;2.3 Testabdeckung;39
9.2.4;2.4 Der Algorithmus zur Änderung von Legacy Code;42
9.3;Kapitel 3: Überwachung und Trennung;45
9.3.1;3.1 Kollaborateure simulieren;47
9.4;Kapitel 4: Das Seam-Modell;53
9.4.1;4.1 Ein riesiges Blatt mit Text;53
9.4.2;4.2 Seams;54
9.4.3;4.3 Seam-Arten;57
9.5;Kapitel 5: Tools;69
9.5.1;5.1 Automatisierte Refactoring-Tools;69
9.5.2;5.2 Mock-Objekte;71
9.5.3;5.3 Unit-Test-Harnische;72
9.5.4;5.4 Allgemeine Test-Harnische;77
10;Teil II: Software ändern;79
10.1;Kapitel 6: Ich habe nicht viel Zeit und ich muss den Code ändern;81
10.1.1;6.1 Sprout Method;83
10.1.2;6.2 Sprout Class;87
10.1.3;6.3 Wrap Method;91
10.1.4;6.4 Wrap Class;95
10.1.5;6.5 Zusammenfassung;100
10.2;Kapitel 7: Änderungen brauchen eine Ewigkeit;101
10.2.1;7.1 Verständlichkeit;101
10.2.2;7.2 Verzögerungszeit;102
10.2.3;7.3 Dependencies aufheben;103
10.2.4;7.4 Zusammenfassung;108
10.3;Kapitel 8: Wie füge ich eine Funktion hinzu?;109
10.3.1;8.1 Test-Driven Development (TDD);110
10.3.2;8.2 Programming by Difference;116
10.3.3;8.3 Zusammenfassung;125
10.4;Kapitel 9: Ich kann diese Klasse nicht in einen Test-Harnisch einfügen;127
10.4.1;9.1 Der Fall des irritierenden Parameters;127
10.4.2;9.2 Der Fall der verborgenen Dependency;134
10.4.3;9.3 Der Fall der verketteten Konstruktionen;138
10.4.4;9.4 Der Fall der irritierenden globalen Dependency;140
10.4.5;9.5 Der Fall der schrecklichen Include-Dependencies;148
10.4.6;9.6 Der Fall der Zwiebel-Parameter;152
10.4.7;9.7 Der Fall des Alias-Parameters;154
10.5;Kapitel 10: Ich kann diese Methode nicht in einem Test-Harnisch ausführen;159
10.5.1;10.1 Der Fall der verborgenen Methode;159
10.5.2;10.2 Der Fall der »hilfreichen« Sprachfunktion;163
10.5.3;10.3 Der Fall des nicht erkennbaren Nebeneffekts;166
10.6;Kapitel 11: Ich muss eine Änderung vornehmen. Welche Methoden sollte ich testen?;173
10.6.1;11.1 Effekte analysieren;173
10.6.2;11.2 Vorwärtsanalyse (Reasoning Forward);179
10.6.3;11.3 Effektfortpflanzung (Effect Propagation);184
10.6.4;11.4 Tools für Effektanalysen;186
10.6.5;11.5 Von der Effektanalyse lernen;188
10.6.6;11.6 Effektskizzen vereinfachen;189
10.7;Kapitel 12: Ich muss in einem Bereich vieles ändern. Muss ich die Dependencies für alle beteiligten Klassen aufheben?;193
10.7.1;12.1 Abfangpunkte;194
10.7.2;12.2 Ein Design mit Einschnürpunkten beurteilen;201
10.7.3;12.3 Fallen bei Einschnürpunkten;203
10.8;Kapitel 13: Ich muss etwas ändern, weiß aber nicht, welche Tests ich schreiben soll;205
10.8.1;13.1 Charakterisierungs-Tests;206
10.8.2;13.2 Klassen charakterisieren;209
10.8.3;13.3 Gezielt testen;210
10.8.4;13.4 Eine Heuristik für das Schreiben von Charakterisierungs-Tests;215
10.9;Kapitel 14: Dependencies von Bibliotheken bringen mich um;217
10.10;Kapitel 15: Meine Anwendung besteht nur aus API-Aufrufen;219
10.11;Kapitel 16: Ich verstehe den Code nicht gut genug, um ihn zu ändern;227
10.11.1;16.1 Notizen/Skizzen;228
10.11.2;16.2 Listing Markup;229
10.11.3;16.3 Scratch Refactoring;230
10.11.4;16.4 Ungenutzten Code löschen;231
10.12;Kapitel 17: Meine Anwendung hat keine Struktur;233
10.12.1;17.1 Die Geschichte des Systems erzählen;234
10.12.2;17.2 Naked CRC;238
10.12.3;17.3 Conversation Scrutiny;241
10.13;Kapitel 18: Der Test-Code ist im Weg;243
10.13.1;18.1 Konventionen für Klassennamen;243
10.13.2;18.2 Der Speicherort für Tests;244
10.14;Kapitel 19: Mein Projekt ist nicht objektorientiert. Wie kann ich es sicher ändern?;247
10.14.1;19.1 Ein einfacher Fall;248
10.14.2;19.2 Ein schwieriger Fall;248
10.14.3;19.3 Neues Verhalten hinzufügen;252
10.14.4;19.4 Die Objektorientierung nutzen;255
10.14.5;19.5 Es ist alles objektorientiert;258
10.15;Kapitel 20: Diese Klasse ist zu groß und soll nicht noch größer werden;261
10.15.1;20.1 Aufgaben erkennen;264
10.15.2;20.2 Andere Techniken;278
10.15.3;20.3 Die nächsten Schritte;278
10.15.4;20.4 Nach dem Extrahieren von Klassen;281
10.16;Kapitel 21: Ich ändere im ganzen System denselben Code;283
10.16.1;21.1 Erste Schritte;286
10.17;Kapitel 22: Ich muss eine Monster-Methode ändern und kann keine Tests dafür schreiben;301
10.17.1;22.1 Spielarten von Monstern;301
10.17.2;22.2 Monster mit automatischer Refactoring-Unterstützung zähmen;306
10.17.3;22.3 Die Herausforderung des manuellen Refactorings;308
10.17.4;22.4 Strategie;316
10.18;Kapitel 23: Wie erkenne ich, dass ich nichts kaputtmache?;319
10.18.1;23.1 »Hyperaware Editing«;319
10.18.2;23.2 »Single-Goal Editing«;321
10.18.3;23.3 »Preserve Signatures«;322
10.18.4;23.4 »Lean on the Compiler«;325
10.19;Kapitel 24: Wir fühlen uns überwältigt. Es wird nicht besser.;329
11;Teil III: Techniken zur Aufhebung von Dependencies;333
11.1;Kapitel 25: Techniken zur Aufhebung von Dependencies;335
11.1.1;25.1 »Adapt Parameter«;335
11.1.2;25.2 »Break Out Method Object«;339
11.1.3;25.3 »Definition Completion«;345
11.1.4;25.4 »Encapsulate Global References«;347
11.1.5;25.5 »Expose Static Method«;353
11.1.6;25.6 »Extract and Override Call«;356
11.1.7;25.7 »Extract and Override Factory Method«;358
11.1.8;25.8 »Extract and Override Getter«;360
11.1.9;25.9 »Extract Implementer«;363
11.1.10;25.10 »Extract Interface«;368
11.1.11;25.11 »Introduce Instance Delegator«;374
11.1.12;25.12 »Introduce Static Setter«;376
11.1.13;25.13 »Link Substitution«;382
11.1.14;25.14 »Parameterize Constructor«;383
11.1.15;25.15 »Parameterize Method«;386
11.1.16;25.16 »Primitivize Parameter«;388
11.1.17;25.17 »Pull Up Feature«;390
11.1.18;25.18 »Push Down Dependency«;394
11.1.19;25.19 »Replace Function with Function Pointer«;397
11.1.20;25.20 »Replace Global Reference with Getter«;400
11.1.21;25.21 Subclass and Override Method;402
11.1.22;25.22 Supersede Instance Variable;405
11.1.23;25.23 »Template Redefinition«;409
11.1.24;25.24 »Text Redefinition«;412
12;Anhang A: Refactoring;415
12.1;A.1 Extract Method;415
13;Anhang B: Glossar;421
14;Stichwortverzeichnis;423

Über Autor(innen)

Michael C. Feathers arbeitet für Object Mentor, Inc., eines der weltweit führenden Unternehmen für Mentoring, Wissenstransfer und Leadership-Services bei der Software-Entwicklung. Gegenwärtig bietet er weltweit Trainings für Test-Driven Development (TDD), Refactoring, OO-Design, Java, C#, C++ und Extreme Programming (XP) an. Feathers ist der ursprüngliche Autor von CppUnit, einer C++-Portierung des JUnit-Test-Frameworks, und FitCpp, einer C++-Portierung des integrierten Test-Framworks FIT. Er ist Mitglied der ACM und des IEEE und war Vorsitzender von CodeFest auf drei OOPSLA-Konferenzen.