Kapitel 7 Refactoring I

Transkript

1 Kapitel 7 Refactoring I Software Engineering FS 2014 Prof. Dr. Jana Köhler jana.koehler@hslu.ch

2 Was ist Refactoring? 2

3 Das Movie Beispiel 3

4 Metriken für Movie 4

5 Die statement() Methode der Customer Klasse public String statement() { double totalamount = 0; int frequentrenterpoints = 0; while (rentals.hasmoreelements()) { double thisamount = 0; Rental each = rentals.nextelement(); //determine amounts for each line switch (each.getmovie().getpricecode()) { case Movie.REGULAR:... } // add frequent renter points // add bonus for a two day new release rental // show figures for this rental // add footer lines... 5

6 Interaktionen der statement() Methode mit anderen Klassen 6

7 Methode extrahieren, Signatur ändern while (rentals.hasmoreelements()) { double thisamount = 0; Rental each = rentals.nextelement(); //determine amounts for each line thisamount = amountfor(each); 7

8 Alles OK? oder doch nicht? 8

9 Es bleibt noch viel zu tun (3) (8) class Customer case Movie.REGULAR: thisamount += 2; if (each.getdaysrented() > 2) thisamount += (each.getdaysrented()-2)*1.5; break; Spezielle Preisberechnungen für hart codierte Filmtypen neue Filmtypen? neue Preisberechnungen? 9

10 Ziel: Replace Conditional with Polymorphism 10

11 Refactoring: Replace Type Code with State/Strategy 11

12 Inhalt des Refactoring Kurses I. Was ist Refactoring? Refactoring und Softwarequalität Bad Smells II. Von Bad Smells zu Refactorings Arbeitsweise, Tool Support, Big Refactorings III. Gastvortrag Dr. Reto Fanger (dieadvokatur.ch & Datenschutzbeauftragter des Kantons Luzern) IV. Ihre Referate zum Thema 12

13 Termine /11. April Input und Gastvortrag 24./25. April: Referate 13

14 Refactoring Vorträge I. Kennenlernen der Bad Smells mind. 2 Beispiele pro Bad Smell II. Kennenlernen der Refactorings "in Action" Durchführung an Beispielen zeigen und auch im Tool III. Refactoring in Eclipse und Visual Studio/Resharper Jeweils 25 Minuten Vortrag, Folien in den Dateiaustausch auf ILIAS 2er Team, bis auf III (2 2erTeams) Wie präsentieren Sie ein "trockenes" Thema spannend? 14 Software Engineering Software Architektur

15 Auswahl eines Refactoring Projektes Entweder ein eigenes Softwareprojekt oder das EnergyBilling Beispiel von Fowler (im ILIAS) Objektorientierter Code Java Eclipse verwenden für optimalen Refactoring Support C# Resharper für Visual Studio Mind. 250 Zeilen und 3-4 Klassen Fremder Code oft spannender 15

16 Dokumentation des Refactoringprojektes Refactorings in der Beispielsoftware mit einem konkreten Refactoringziel durcharbeiten In der Doku für ILIAS die folgenden Fragen beantworten: Welches Problem wird bearbeitet? Welches Refactoringziel verfolgen Sie? Wie messen Sie den Fortschritt? Wie ist der Zustand der Software zu Beginn? Wie hat sich der Zustand im Hinblick auf Ihr Ziel verbessert? Ihre am häufigsten verwendeten Refactorings Ihr Fazit zum Thema Einschreiben in Projektliste (1 bis max. 3 Namen pro Team) Abgabe bis (alle) in den Briefkasten auf ILIAS 16

17 2011: Qualitätsfortschritte in den Projekten Projekte Energie Billing (7) GUI Builder (2) Yatzy Java Voice Bridge Ziele Metriken verbessern Designkomplexität reduzieren Klassengrösse, Klassenbeziehungen, Vererbung, Wartbarkeit erhöhen Verständlichkeit verbessern, Vereinfachungen Deprecated code eliminieren Verwendete Qualitätsmasse Tool Warnings / Metriken (7) Von 29 auf 14 Warnungen reduziert Von 436 LOC auf 310 (Nebeneffekt: 1 CyC < Grenzwert) Max LOC von 48 auf 14, Max CyC von 16 auf 9, Max weighted methods per class von 30 auf 25 Codevergleiche (2) Klassendiagramme vorher nachher (6) Qualitative Beschreibung (Text) (5)

18 2012: Refactoring Projekte Projekte: Energy, GUI Refactoring, Spiele, Pfadi Leihsystem, Projektmanagement, diverse Android Apps Ziele: Verständlichkeit verbessern (lange Methoden, Vereinfachungen von Schnittstellen), Wartbarkeit erhöhen, Designkomplexität reduzieren (Klassengrösse, Klassenbeziehungen, Vererbung), Testprobleme angehen, sekundär: Metriken verbessern Smells: Duplicated code, Long method, Switch statements, (Cyclomatic complexity), Long parameter lists, Inappropriate intimacy, Feature envy, Comments, Lazy class, Incomplete library class, Primitive obsession, Alternative classes with different interfaces Refactorings Rename method, extract method, move method/field, extract class, pull up method/field, extract superclass, Inline class, Introduce parameter (object), Replace data value with object, Replace type code with state/strategy Decompose conditional expression, Introduce foreign method Fortschritte gemessen wie 2011 Grenzen der Metriken beobachtet

19 Beispiel: Issues bei Code Inspection

20 Beispiel: Analyse mit NDepend

21 Beispiel: Entwicklung Metriken/Klassendiagram

22 Das Energy Billing Beispiel von Fowler Ca. 100seitiges, ursprüngliches Buchkapitel, das aber nicht in die Endversion des Buches aufgenommen wurde Szenario Erstellen einer Stromrechnung auf der Basis des Stromverbrauchs (berechnet anhand der letzten Ablesungen "readings") 4 Arten von Kunden in 4 Klassen Residential, Disability, Lifeline, Business Charge() Methode für jede Klasse Hauptziel: Aufbau einer guten Klassenhierarchie durch Refactoring Weitere mögliche Ziele: siehe mein Kommentar in den Tests 22

23 Ausgangssituation Energy Billing 23

24 Literatur Semesterapparat in der Bibliothek (1 x D, 3 x E), Ebook auf ILIAS "This book explains the principles and best practices of refactoring and where you should start digging in your code to improve it." Erich Gamma im Vorwort des Buches 24

25 Lernziele I Refactoring als wesentliche Methode, um die Qualität einer Software nachhaltig zu sichern Bewertung von Softwarequalität und Folgen schlechter Softwarequalität Unterschied zwischen Refactoring, Funktionserweiterung, Performanceoptimierung, Technologieportierung als verschiedene Aufgaben während der Softwareentwicklung Projektmanagementwissen um ein bewusstes Einplanen von Refactoring erweitern 25

26 Lernziele II Konkrete Alarmzeichen (Bad Smells) im Code erkennen Von den Alarmzeichen auf die anzuwendenden Refactoringmethoden schliessen und diese aktiv beherrschen Zyklus Code Visualization Metrics Bad Smells Refactor Test Professionelles Tool mit Refactoring Support verwenden 26

27 Refactoring Definition M. Fowler "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chance of introducing bugs. In essence when you refactor, you improve the design of the code after it has been written. With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. Yet the cumulative effect of these small changes can radically improve the design." 27

28 The Essence of Refactoring " process of changing a software system does not alter the external behavior of the code improves its internal structure disciplined way to clean up code improve the design of code after it has been written Each step is simple, even simplistic Yet the cumulative effect of these small changes can radically improve the design " 28

29 2 mögliche Interpretationen "Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior." - als Prozess "Refactoring (noun): A small change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior." - als Strukturmodifikation 29

30 Das Design verbessern, indem man den Code verbessert Der Untertitel lautet nicht "Improving Existing Code" 30

31 Waterfall Approach vs. Software Evolution "In our current understanding of software development we believe that we design and then we code." Good design comes first, coding comes second "Over time, the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking." 31

32 Twin Peaks Modell von Nuseibeh 32

33 Design im Spannungsfeld von Architektur & Implementation "With refactoring you find the balance of work changes." Learn from building the system how to improve the design Keep code (and design) easier to understand/modify [Woods, ECSA 2010] 33

34 Wann wird Refactoring angewandt? 34

35 Anwendungszenarien für Refactoring I Bevor neue Funktionalität zu bestehender Software hinzugefügt wird Design auf neue Anforderungen anpassen Flexibilität des Designs dann einführen, wenn wirklich gebraucht Beim Einarbeiten in unbekannte Software / code reviews Eigenes Verständnis durch strukturelle Änderungen des Codes dokumentieren Tests helfen, das Verständnis zu verifizieren 35

36 Anwendungszenarien für Refactoring II Zur Isolierung und Identifikation von Fehlern "I find that if I refactor code, I work deeply on understanding what the code does, and I put that new understanding right back into the code. By clarifying the structure of the program, I clarify certain assumptions I've made, to the point at which even I can't avoid spotting the bugs." Testsuite verbessern Wenn neue Anforderungen schwierig in die Software eingefügt werden können Wenn sich Anzeichen für schlechte Qualität häufen 36

37 Anwendungszenarien für Refactoring III Zur Verbesserung der Entwicklungsproduktivität "A good design is essential to maintaining speed in software development. Refactoring helps you develop software more rapidly, because it stops the design of the system from decaying. It can even improve the design." Three strikes and you refactor "The first time you do something, just do it. The second time you do something similar, you wince at the application, but you do the duplicate thing anyway. The third time, you do something similar, you refactor." 37

38 Verbesserte Effizienz und Qualität als Motivation P. Welsh: Continuous Refactoring and the Cost of Decay Kosten für Funktionalitätsänderungen über die Lebenszeit der Software

39 Aufgabe 1 Lesen Sie das Kurzgutachten zur Softwarequalität (7 Seiten, 8 Seiten Anhang) I. Nach welchen Gesichtspunkten wird die Software begutachtet? II. Welche Kriterien werden für die Einschätzung der Codequalität verwendet? 39

40 Anzeichen für mangelnde Code (Design) Qualität im Gutachten Viele globale Variablen Verstreute Zugriffe auf diese Variablen Schlecht verständliche Methoden- und Variablennamen Fehlende und schlecht verständliche Kommentare Fehlerbehandlung nicht explizit vorhanden Kopierter / redundanter Code Bad Smells (Kent Beck) describing the "when" of refactoring certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring 40

41 Bad Smells I Duplicated Code Long Method Large Class Long Parameter List Feature Envy Switch Statements Inappropriate Intimacy Lazy Class Data Class Message Chains Middle Man Comments Duplizierter Code Lange Methode Grosse Klasse Lange Parameterliste Neid Switch-Befehle Unangebrachte Intimität Faule Klasse Datenklasse Nachrichtenketten Vermittler Kommentare 41

42 Bad Smells II Divergent Change Shotgun Surgery Data Clumps Primitive Obsession Parallel Inheritance Hierarchies Speculative Generality Temporary Field Alternative Classes with Different Interfaces Incomplete Library Class Refused Bequest Divergierende Änderungen Schrotkugeln herausoperieren Datenklumpen Neigung zu elementaren Typen Parallele Vererbungshierarchien Spekulative Allgemeinheit Temporäre Felder Alternative Klasse mit verschiedenen Schnittstellen Unvollständige Bibliotheksklasse Ausgeschlagenes Erbe 42 Beispiele in Ihren Vorträgen geben!

43 Nach welchem Kriterium habe ich die Gruppen 1 und 2 der Bad Smells gebildet? 43

44 Metriken und Bad Smells Long Method Lines of Code in Method Number Of Statements Large Class Weighted Methods Per Class Long Parameter List Number Of Parameters Feature Envy Feature Envy Switch Statements McCabe's Cyclomatic Complexity Inappropriate Intimacy Efferent Couplings 44

45 2011: Gefundene Bad Smells Duplicated Code (6) Long Method (3) Feature Envy (3) Speculative Generality (3) Large Class (2) Temporary Field (2) Primitive Obsession (2) Shotgun Surgery (2) Middle Man Lazy Class

46 Von Bad Smells zu Refactorings Auf ILIAS und im hinteren Buchumschlag In der Beschreibung der Smells, Buchkapitel 3. und verstreut im ganzen Buch 46

47 Der Refactorings Katalog Fokus: Objekt-orientierte Programmierung Keine Unterstützung von speziellen Refactorings für Parallele Programme Verteilte Systeme (JEE/SOA Applikationen) Datenbank-Applikationen Echtzeit-Software Detaillierte Beschreibung im Buch, Kurzbeschreibung unter 47

48 Beschreibung der Refactorings im Buch Name: Ein intuitiver und eindeutiger Name Summary: In welcher Situation anwenden und was es tut Motivation: Warum das Refactoring angewendet werden sollte und Umstände, unter denen man es besser nicht anwendet Mechanics: Präzise Schritt-für-Schritt Anleitung wie man das Refactoring ausführt Examples: Beispiel(e) wie das Refactoring funktioniert 48

49 Online Kurzbeschreibung 49

50 6 Hauptgruppen von Refactorings im Buch (Ihre Vorträge) Chapter 6) Composing Methods 7) Moving Features between Objects 8) Organizing Data 9) Simplifying Conditional Expressions 10)Making Method Calls Simpler 11)Dealing with Generalization 50

51 Tool Support Refactoring ist Standard in guten Tools Am weitesten entwickelt in Eclipse Kontextsensitive Menüs Aktive Vorschläge Preview/Problems page Auch als Quick Assists Detailliert dokumentiert Eigener Katalog Resharper für Visual Studio 51

52 Aufgabe (Vorbereitung Ihres Vortrags) Lesen Sie Kapitel 3 zu Bad Smells aus dem Refactoring Buch. I. Welche Bad Smells erkennen Sie in den Kritikpunkten des Gutachtens wieder? II. Inwieweit sind Fowler s Bad Smells auf die begutachtete Art von Software anwendbar? III. Welche Information zur begutachteten Software fehlt Ihnen, um eine vollständige Analyse auf alle Bad Smells vornehmen zu können? Überlegen Sie sich die Antworten zu diesen Fragen wenn Sie Ihren Vortrag vorbereiten! 52

53 Arbeitsfragen 1. Was versteht man unter Refactoring? 2. Warum ist Refactoring wichtig? 3. Wann wird Refactoring angewendet? 4. Wann sollten Sie kein Refactoring durchführen? 5. Warum sind automatisierte Tests eine unabdingbare Voraussetzung? 6. Welche Risiken gehen Sie ein, wenn Sie keine automatischen Tests verweden? 7. Müssen Sie Tests anpassen, wenn Sie "gerefactored" haben? 8. Nennen Sie Beispiele für Bad Smells und erläutern Sie mögliche Refactorings. 9. Wie können Sie Bad Smells feststellen? 10. Welche Refactorings sind am häufigsten und warum? 11. Was sollte ein gutes Refactoring Tool leisten? 53