Loading…
Effektives Arbeiten mit Legacy Code : Refactoring und Testen bestehender Software /
Deutsche Übersetzung des Klassikers von Michael Feathers Holen Sie mehr aus Ihren Legacy-Systemen heraus: mehr Performance, Funktionalität, Zuverlässigkeit und Handhabbarkeit Mit einem Vorwort von Robert C. Martin Können Sie Ihren Code leicht ändern? Können Sie fast unmittelbar Feedback bekomm...
| Call Number: | Libro Electrónico |
|---|---|
| Main Author: | |
| Format: | Electronic eBook |
| Language: | Alemán Inglés |
| Published: |
[Frechen] :
MITP,
2011.
|
| Subjects: | |
| Online Access: | Texto completo (Requiere registro previo con correo institucional) |
Table of Contents:
- Cover; Titel; Impressum; Inhaltsverzeichnis; Vorwort; Geleitwort; Danksagungen; Einführung
- Wie man dieses Buch lesen sollte; Teil I: Wie Wandel funktioniert; Kapitel 1: Software ändern; 1.1 Vier Gründe, Software zu ändern; 1.2 Riskante Änderungen; Kapitel 2: Mit Feedback arbeiten; 2.1 Was sind Unit-Tests?; 2.2 Higher-Level-Tests; 2.3 Testabdeckung; 2.4 Der Algorithmus zur Änderung von Legacy Code; Kapitel 3: Überwachung und Trennung; 3.1 Kollaborateure simulieren; Kapitel 4: Das Seam-Modell; 4.1 Ein riesiges Blatt mit Text; 4.2 Seams; 4.3 Seam-Arten; Kapitel 5: Tools
- 5.1 Automatisierte Refactoring-Tools5.2 Mock-Objekte; 5.3 Unit-Test-Harnische; 5.4 Allgemeine Test-Harnische; Teil II: Software ändern; Kapitel 6: Ich habe nicht viel Zeit und ich muss den Code ändern; 6.1 Sprout Method; 6.2 Sprout Class; 6.3 Wrap Method; 6.4 Wrap Class; 6.5 Zusammenfassung; Kapitel 7: Änderungen brauchen eine Ewigkeit; 7.1 Verständlichkeit; 7.2 Verzögerungszeit; 7.3 Dependencies aufheben; 7.4 Zusammenfassung; Kapitel 8: Wie füge ich eine Funktion hinzu?; 8.1 Test-Driven Development (TDD); 8.2 Programming by Difference; 8.3 Zusammenfassung
- Kapitel 9: Ich kann diese Klasse nicht in einen Test-Harnisch einfügen9.1 Der Fall des irritierenden Parameters; 9.2 Der Fall der verborgenen Dependency; 9.3 Der Fall der verketteten Konstruktionen; 9.4 Der Fall der irritierenden globalen Dependency; 9.5 Der Fall der schrecklichen Include-Dependencies; 9.6 Der Fall der Zwiebel-Parameter; 9.7 Der Fall des Alias-Parameters; Kapitel 10: Ich kann diese Methode nicht in einem Test-Harnisch ausführen; 10.1 Der Fall der verborgenen Methode; 10.2 Der Fall der "hilfreichen" Sprachfunktion; 10.3 Der Fall des nicht erkennbaren Nebeneffekts
- Kapitel 11: Ich muss eine Änderung vornehmen. Welche Methoden sollte ich testen?11.1 Effekte analysieren; 11.2 Vorwärtsanalyse (Reasoning Forward); 11.3 Effektfortpflanzung (Effect Propagation); 11.4 Tools für Effektanalysen; 11.5 Von der Effektanalyse lernen; 11.6 Effektskizzen vereinfachen; Kapitel 12: Ich muss in einem Bereich vieles ändern. Muss ich die Dependencies für alle beteiligten Klassen aufheben?; 12.1 Abfangpunkte; 12.2 Ein Design mit Einschnürpunkten beurteilen; 12.3 Fallen bei Einschnürpunkten; Kapitel 13: Ich muss etwas ändern, weiß aber nicht, welche Tests ich schreiben soll
- 13.1 Charakterisierungs-Tests13.2 Klassen charakterisieren; 13.3 Gezielt testen; 13.4 Eine Heuristik für das Schreiben von Charakterisierungs-Tests; Kapitel 14: Dependencies von Bibliotheken bringen mich um; Kapitel 15: Meine Anwendung besteht nur aus API-Aufrufen; Kapitel 16: Ich verstehe den Code nicht gut genug, um ihn zu ändern; 16.1 Notizen/Skizzen; 16.2 Listing Markup; 16.3 Scratch Refactoring; 16.4 Ungenutzten Code löschen; Kapitel 17: Meine Anwendung hat keine Struktur; 17.1 Die Geschichte des Systems erzählen; 17.2 Naked CRC; 17.3 Conversation Scrutiny