Kapitel 3 Software Quality III

Transkript

1 Kapitel 3 Software Quality III Software Architecture, Quality, and Testing FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch

2 Agenda Heute Von Bad Smells zu Refactorings Wie wird Refactoring durchgeführt? "Verschiedene Hüte tragen" Zyklus Codevisualisierung Metriken Bad smells Refactorings Testen Grosse Refactorings Zusammenfassung

3 Verschiedene Software Engineering Aufgaben Metapher der verschiedenen Hüte Für ein Ziel entscheiden, konsequent daran arbeiten Wenn notwendig, ebenso konsequent unterbrechen und am neuen Ziel arbeiten Dann Arbeit am ursprünglichen Ziel wieder aufnehmen Refactoring Funktionserweiterung Performanceoptimierung Technologieportierung Refactoring schafft verbesserte Bedingungen für die anderen Aufgaben

4 Problem "Wearing Multiple Hats at a Time"

5 Kleine Schritte und häufiges Testen Integraler Bestandteil der Entwicklung Bei kontinuierlicher Anwendung nur in kurzen Intervallen Ist das Design degradiert, intensive Phasen notwendig Kontrolliertes und effizientes Durchführen von strukturellen Änderungen Kleine Schritte Methodische Strukturverbesserungen "To avoid digging your own grave, refactoring must be done systematically." Eng verknüpft mit automatischen Tests

6 Zyklische Arbeitsweise beim Refactoring effiziente Einstiegspunkte durch Toolingfortschritte Code visualisieren Metriken messen wichtigster Einstiegspunkt Bad Smells identifizieren Refactoring anwenden Testen Hauptzyklus

7 Risiken und Herausforderungen I Neuschreiben ist die bessere Alternative "Remember, code has to work mostly correctly when you refactor." Zu viele Fehler Design aufgrund zu vieler Abhängigkeiten kaum zu ändern Komplett geänderte Anforderungen, neue Technologien Das Refactoringziel aus den Augen verlieren Einen Plan notieren Rechtzeitig aufhören

8 Risiken und Herausforderungen II "It requires changes to working code that can introduce subtle bugs." Testqualität und Toolsupport reduzieren Fehlerquote Häufiges Testen grenzt Fehlerbereich ein Der Produktivitätsgewinn setzt zu spät ein Refactoring als Investition in die Zukunft Kein Refactoring kurz bevor der Projektabgabe aber: "Not having enough time usually is a sign that you need to do some refactoring."

9 Grosse Refactorings Design in grossen Projekten verändern und verbessern Den kumulierten Nutzen vieler kleiner Refactorings explizit machen Grundlegende Unterschiede zu kleinen Refactorings Benötigen viel mehr Zeit Auswirkungen sind nicht direkt vorhersehbar Sichtbarer Fortschritt stellt sich erst nach vielen kleinen Refactorings ein Erfolge oft erst nach intensiver Arbeit / Frustrationsphasen Zustimmung im Entwicklungsteam notwendig

10 Tease Apart Inheritance

11 Convert Procedural Designs into Objects

12 Separate Domain from Presentation

13 Extract Hierarchy

14 Tipps für den grossen Umbau Refactoring footprint = number of features affected by a refactoring Sven Gorts, Je grösser der Footprint, desto grösser das Risiko Den Footprint klein halten In kleinen Schritten arbeiten (alle Refactorings aus dem Buch) Design stages einführen Grössere Zwischenziele für das Design festlegen Prioritäten setzen Refactoring Plan mit dokumentierten Entscheidungen Richtung festlegen für viele kleine Refactorings

15 Refactoring Thumbnails

16 Balance halten zwischen Expansion und Kontraktion "Refactoring is the art of first making duplication explicit and then eliminating it." Sven Gorts,

17 Aufgabe 1: Kurzvorträge Refactorings

18 Mehr zu Refactoring

19 Zusammenfassung: Wesentliche Begriffe Software Qualität Code Qualität Metriken Automatische Tests Bad Smells als Anzeichen für mangelnde Codequalität Refactoring als Prozess Refactoring als Strukturmodifikation

20 Zusammenfassung: Refactoring als Prozess effiziente Einstiegspunkte durch Toolingfortschritte Code visualisieren Metriken messen Wann? Wie? Risiken? wichtigster Einstiegspunkt Bad Smells identifizieren Refactoring anwenden Testen Hauptzyklus

21 Zusammenfassung: Refactoring als Strukturmodifikation Footprint Refactoring Katalog Grosse Refactorings Besseres Design Tool Support Eclipse Ziel/Plan Expansion/Kontraktion Qualität

22 Arbeitsfragen 1. Warum sollten Refactoring Phasen im Projekt von anderen Änderungen im Code klar getrennt werden? 2. Diskutieren Sie die Metapher der verschiedenen Hüte. 3. Welchen Risiken begegnen Sie beim Refactoring und wie können Sie sie reduzieren? 4. Was ist der Footprint eines Refactorings? 5. Wozu können thumbnails beim Refactoring helfen? 6. Was versteht man unter grossen Refactorings und worin liegt der wesentliche Unterschied zu den kleinen Refactoring Schritten? 7. Nennen Sie Beispiele für grosse Refactorings. 8. Welche Informationen können Code Visualisierungen im Zusammenhang mit Refactoring liefern? Nennen Sie Beispiele. 9. Ändert sich Refactoring für Web Applikationen oder in der Cloud?

23 Danke für's Mitmachen!