Software-Sanierung. Weiterentwicklung, Testen und Refactoring bestehender Software. von Sebastian Kübeck. 1. Auflage

Transkript

1 Software-Sanierung Weiterentwicklung, Testen und Refactoring bestehender Software von Sebastian Kübeck 1. Auflage Software-Sanierung Kübeck schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv 2009 Verlag C.H. Beck im Internet: ISBN

2 Sebastian Kübeck Software-Sanierung Weiterentwicklung, Testen und Refactoring bestehender Software

3 Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über < abrufbar. Bei der Herstellung des Werkes haben wir uns zukunftsbewusst für umweltverträgliche und wiederverwertbare Materialien entschieden. Der Inhalt ist auf elementar chlorfreiem Papier gedruckt. ISBN Auflage Telefon: / Telefax: / mitp, eine Marke der Verlagsgruppe Hüthig Jehle Rehm GmbH Heidelberg, München, Landsberg, Frechen, Hamburg IT -fachportal.de Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Lektorat: Sabine Schulz Sprachkorrektorat: Petra Heubach-Erdmann Satz: III-satz, Husby, Druck: Köppl & Schönfelder, Stadtbergen

4 Einleitung Teil I Grundlagen Objektorientierte Programmierung diesmal richtig Die prozedurale Programmierung Die objektorientierte Programmierung Abstraktion Datenkapselung Vererbung Polymorphie Vorteile der objektorientierten Programmierung Die mathematische Theorie der abstrakten Datentypen Die objektorientierte Modellierung UML Das Problem mit dem Umlernen Das Problem mit der Zweckentfremdung von Programmiersprachen Automatisierte Tests Fehler in Programmen Methoden zum Aufspüren von Fehlern Werkzeuge zur Laufzeitüberprüfung SUnit und die testgetriebene Softwareentwicklung JUnit Methoden zur Überprüfung von Testergebnissen Methoden für Vor- und Nacharbeiten Test-Suiten Fallbeispiel: Maximum-Bestimmung Testimplementierung (Test Double) Teststrunk (Test Stub)

5 2.7.2 Testattrappe (Mock Object) Fake-Objekt (Fake Object) Dummy-Objekt (Dummy Object) Arten von automatisierten Tests Entwicklertests Externe Tests Abnahmetests (Acceptance Tests) Integrationstests (Integration Tests) Lasttests (Load Tests, Performance Tests) Andere Arten der Kategorisierung Eigenschaften guter Tests Sorgfältig (Voll-)Automatisch Performant Vollständig Wiederholbar Unabhängig Stabil Entwicklungsprinzipien der objektorientierten Programmierung Interface-Aufteilungsprinzip (Interface Segregation Principle) Liskov-Substitutionsprinzip (Liskov Substitution Principle) Abhängigkeits-Inversionsprinzip (Dependency-Inversion Principle) Einzelzuständigkeitsprinzip (Single-Responsibility Principle) Erweiterungsprinzip (Open-Closed Principle) Entwurfsmuster der objektorientierten Programmierung Abstrakte Fabrik (Abstract Factory) Schablonenmethode (Template Method) Wertobjekte (Value Object) Null-Objekt (Null Object) Stellvertreter (Proxy) Adapter (Adaptor) Beobachter (Observer) Fassade (Facade) Kommando (Command, Transaction, Operation)

6 4.10 Strategie (Strategy) Weitere Entwurfsmuster Wie man Entwurfsmuster nicht verwendet Refactoring Refactoring in unterschiedlichen Größenordnungen Umbenennen von Bezeichnern Methode extrahieren (Extract Method) Methode auflösen (Inline Method) Methode verschieben (Move Method) Methode hochziehen (Pull-Up Method) Interface extrahieren (Extract Interface) Klasse extrahieren (Extract Class) Ein Schritt nach dem anderen Refactorings skizzieren Fehlerbehandlung Die Anfänge Ausnahmebehandlung Der dreiphasige Prozess Fehlerauslösung Fehlerweiterleitung Gruppieren von Fehlern Fehlerprotokollierung und Kompensation Ein Beispiel Teil II Weiterentwicklung bestehender Systeme ohne vorhandene Tests Bestehende Systeme mit Tests erweitern Irgendwo muss man anfangen Fachlogik unabhängig vom Bestandssystem entwickeln Bestandssystem gegen Testimplementierung entwickeln Beispiel mit komplexerer Fassade Schritt für Schritt zu besserem Code Abschotten neuer Funktionalitäten durch implizite Tests Währungsobjekt mit unzureichender Parametervalidierung Verbesserte Kommunikation durch implizite Tests

7 Teil III Bestehende Systeme mit Tests absichern Hindernisse beim Anbringen von Tests Abhängigkeiten Statische Abhängigkeiten Laufzeitabhängigkeiten Überprüfung von Laufzeitabhängigkeiten vor der Programmausführung Überprüfen von Laufzeitabhängigkeiten in der Produktion Eingebettete Sprachen und öffentliche APIs Abhängigkeiten, die die Erstellung von Tests behindern Wo sollte man zuerst Tests anbringen? Wenn Sie einen Fehler finden Auflösen von Abhängigkeiten mithilfe von Testimplementierungen Fallbeispiel: Sequenz-Generator Verbessern der Testabdeckung durch Beobachter Auflösen von Abhängigkeiten durch Ableitung (Object Seam) Fallbeispiel: Authentifizierung an LDAP-Verzeichnis Tests für die Fehlerbehandlung Auflösen von Abhängigkeiten durch Beibehalten der Signatur (Link Seam) Fallbeispiel: Java-Mail-API Entfernen von unnötigen Duplikaten Automatisches Generieren von Tests Einweg-Generatoren Regenerierende Generatoren Round-Trip-Generatoren Entwickeln von Testgeneratoren Teil IV Refactoring bestehender Systeme Erste Schritte hin zu besserem Code Refactoring oder Reengineering?

8 14.2 Wo sollte man mit dem Refactoring beginnen? Die»tägliche Hygiene« Aufteilen großer Klassen Zusammenfassen von Parametern durch Wertobjekte Entfernen von Duplikaten Entfernen von Duplikaten durch Vererbung Entfernen von Duplikaten durch Delegation Automatisches Aufspüren von Duplikaten Duplikate außerhalb des Quellcodes Aufteilung bedingter Logik Umwandeln von Typcodes in Objekte Aufteilen von Verteilern durch Kommandos Aufteilen von Algorithmen durch Strategie Refactoring von Logging und Fehlerbehandlung Ersetzen von Logging durch Beobachter Ersetzen mangelhafter Fehlerbehandlung durch Exceptions Refactoring der Datenzugriffsschicht Aufteilen von Active Records Zusammenfassen von Finder-Methoden durch Filter Einschub: Erweiterte Filter Teil V Anhang A.1 Software-Sanierung Ein nicht zu unterschätzender Aufwand A.1.1 Damit es nicht wieder soweit kommt A.2 Referenzen A.2.1 Einleitung A.2.2 Teil 1 Grundlagen A.2.3 Teil 2 Weiterentwicklung bestehender Systeme ohne vorhandene Tests A.2.4 Teil 3 Bestehende Systeme mit Tests absichern A.2.5 Teil 4 Refactoring bestehender Systeme Stichwortverzeichnis