SlideShare ist ein Scribd-Unternehmen logo
Advanced Refactoring Patterns
Advanced Refactoring Patterns
Advanced Refactoring Patterns
Advanced Refactoring Patterns
Refactoring bezeichnet in der Software-Entwicklung die manuelle oder
automatisierte Strukturverbesserung von Quelltexten unter Beibehaltung des
beobachtbaren Programmverhaltens.
Dabei sollen die Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit
verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und
funktionale Erweiterungen deutlich zu senken.
Quelle: https://de.wikipedia.org/wiki/Refactoring
…is a disciplined technique for restructuring an existing body of
code, altering its internal structure without changing its external
behavior.
Its heart is a series of small behavior preserving transformations.
Each transformation (called a “refactoring”) does little, but a
sequence of transformations can produce a significant
restructuring. Since each refactoring is small, it’s less likely to go
wrong. The system is kept fully working after each small
refactoring, reducing the chances that a system can get seriously
broken during the restructuring.
refactoring.com
Add Parameter Introduce Class Annotation Replace Conditional with Polymorphism
Change Bidirectional Association to Unidirectional Introduce Expression Builder Replace Constructor with Factory Method
Change Reference to Value Introduce Foreign Method Replace Data Value with Object
Change Unidirectional Association to Bidirectional Introduce Gateway Replace Delegation With Hierarchy
Change Value to Reference Introduce Local Extension Replace Delegation with Inheritance
Collapse Hierarchy Introduce Named Parameter Replace Dynamic Receptor with Dynamic Method Definition
Consolidate Conditional Expression Introduce Null Object Replace Error Code with Exception
Consolidate Duplicate Conditional Fragments Introduce Parameter Object Replace Exception with Test
Decompose Conditional Isolate Dynamic Receptor Replace Hash with Object
Duplicate Observed Data Lazily Initialized Attribute Replace Inheritance with Delegation
Dynamic Method Definition Move Eval from Runtime to Parse Time Replace Loop with Collection Closure Method
Eagerly Initialized Attribute Move Field Replace Magic Number with Symbolic Constant
Encapsulate Collection Move Method Replace Method with Method Object
Encapsulate Downcast Parameterize Method Replace Nested Conditional with Guard Clauses
Encapsulate Field Preserve Whole Object Replace Parameter with Explicit Methods
Extract Class Pull Up Constructor Body Replace Parameter with Method
Extract Interface Pull Up Field Replace Record with Data Class
Extract Method Pull Up Method Replace Subclass with Fields
Extract Module Push Down Field Replace Temp with Chain
Extract Subclass Push Down Method Replace Temp with Query
Extract Superclass Recompose Conditional Replace Type Code with Class
Extract Surrounding Method Remove Assignments to Parameters Replace Type Code with Module Extension
Extract Variable Remove Control Flag Replace Type Code With Polymorphism
Form Template Method Remove Middle Man Replace Type Code with State/Strategy
Hide Delegate Remove Named Parameter Replace Type Code with Subclasses
Hide Method Remove Parameter Self Encapsulate Field
Inline Class Remove Setting Method Separate Query from Modifier
Inline Method Remove Unused Default Parameter Split Temporary Variable
Inline Module Rename Method Substitute Algorithm
Inline Temp Replace Abstract Superclass with Module
Introduce Assertion Replace Array with Object
refactoring.com
“Code without tests is bad code. It doesn't matter
how well written it is; it doesn't matter how pretty
or object-oriented or well-encapsulated it is. With
tests, we can change the behavior of our code
quickly and verifiably. Without them, we really
don't know if our code is getting better or worse.”
Advanced Refactoring Patterns
Advanced Refactoring Patterns
Advanced Refactoring Patterns
1. Quellcode einchecken.
2. Einen Überblick darüber verschaffen was geändert werden soll.
3. Mindestens einen Test schreiben der das bestehende Verhalten
charakterisiert.
4. Refaktorisieren
5. Prüfen ob sich das Verhalten verändert hat.
Situationen
„Ich weiß nicht was mein Code macht, soll diesen Zustand aber ändern.“
Vorgehen
Wir schreiben einen Test ohne Asserts und sehen uns anhand der
Codeabdeckung an was passiert.
Situationen
„Ich will das mein Code sich nach den Änderungen so verhält wie vorher.“
Vorgehen
Man schreibt oder generiert einen oder mehrere Tests um das Verhalten zu
prüfen.
Advanced Refactoring Patterns
Situationen
„Ich muss Interna einer Klasse manipulieren um etwas testen zu können, will
dies aber nur für die Tests tun.“
?!?Test
Accessor
?!?Test
Situationen
„Wir haben keine Zeit für umfassende Refactorings.“
„Ich möchte Code testgetrieben in einer untestbaren Umgebung umsetzen.“
„Ich kann das Problem durch reines Hinzufügen von Code lösen.“
?!?
Test
?!?
Test
Sprout
?!?
Test
Sprout
Situationen
„Ich muss eine vorhandene Schnittstelle ändern, möchte das Verhalten aber
nicht unvorhergesehen schädigen.“
?!? ?!? ?!?
?!?
?!? ?!? ?!?
?!?
?!? ?!? ?!?
?!?
?!? ?!? ?!?
?!?
?!? ?!? ?!?
?!?
Situationen
„Ich habe eine Klasse/Methode die viel zu komplex ist.“
Vorgehen
Wir lagern komplexe Methoden in eigene Klassen aus und brechen sie dort in
weitere Methoden auf.
?!?
?!??!?
?!? ?!?
A
B
C
D
Situationen
„Ich muss ein altes System ablösen, es ist aber so komplex, dass ich dies nicht
mit einen Mal tun kann. “
Vorgehen
Wir bauen das neue System als Sprouts, ziehen schrittweise die Funktionalität
aus dem alten und entfernen all die Teile die nicht mehr im alten gebraucht
werden.
?!? ?!?
?!?
!!!
!!! ?!? ?!?
?!?
!!!
!!! ?!? ?!?
?!?
!!!
!!! ?!? ?!?
?!?
!!!
!!! ?!? ?!?
!!!
!!! ?!? ?!?
Advanced Refactoring Patterns
Quelle: https://martinfowler.com/bliki/RefactoringMalapropism.html
Refactoring
• Kleine lokale Änderungen.
• Schnelle Anpassungen mit geringen Auswirkungen auf
andere.
• Können ohne größere Absprache durchgeführt werden.
• Keine tiefgreifenden architekturellen Anpassungen in
bestehendem Code.
Restructuring
• Großflächige architekturelle Anpassungen die sich
auf die Gesamtapplikation auswirken können.
• Können andere Entwickler behindern.
• Sollten nicht ohne Absprache und Planung
durchgeführt werden.

Weitere ähnliche Inhalte

Ähnlich wie Advanced Refactoring Patterns

Anforderungsanalyse und UML Grundlagen
Anforderungsanalyse und UML GrundlagenAnforderungsanalyse und UML Grundlagen
Anforderungsanalyse und UML Grundlagen
Christian Baranowski
 
MVVM mit WPF
MVVM mit WPFMVVM mit WPF
MVVM mit WPF
Hendrik Lösch
 
react-de.pdf
react-de.pdfreact-de.pdf
react-de.pdf
ssuser65180a
 
AdvancedTdd
AdvancedTddAdvancedTdd
AdvancedTdd
jlink
 
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreHands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Gregor Biswanger
 
Testgetriebene Softwareentwicklung
Testgetriebene SoftwareentwicklungTestgetriebene Softwareentwicklung
Testgetriebene Softwareentwicklung
jlink
 
Große Applikationen mit AngularJS
Große Applikationen mit AngularJSGroße Applikationen mit AngularJS
Große Applikationen mit AngularJS
Sebastian Springer
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testen
mradamlacey
 
Einführung in Clean Code mit .NET - Teil 1
Einführung in Clean Code mit .NET - Teil 1Einführung in Clean Code mit .NET - Teil 1
Einführung in Clean Code mit .NET - Teil 1
Gregor Biswanger
 
Implementierung der Knowledge Engineering Workbench in myCBR
Implementierung der Knowledge Engineering Workbench in myCBRImplementierung der Knowledge Engineering Workbench in myCBR
Implementierung der Knowledge Engineering Workbench in myCBR
Alexander Hundt
 
Metaprogrammierung und Reflection
Metaprogrammierung und ReflectionMetaprogrammierung und Reflection
Metaprogrammierung und Reflection
Stefan Marr
 
magnolia mit thymeleaf - ein agiler prozess-beschleuniger
magnolia mit thymeleaf - ein agiler prozess-beschleunigermagnolia mit thymeleaf - ein agiler prozess-beschleuniger
magnolia mit thymeleaf - ein agiler prozess-beschleuniger
Thomas Kratz
 
W-JAX 2013 Spring Batch - Performance und Skalierbarkeit
W-JAX 2013 Spring Batch - Performance und SkalierbarkeitW-JAX 2013 Spring Batch - Performance und Skalierbarkeit
W-JAX 2013 Spring Batch - Performance und Skalierbarkeit
tobiasflohre
 
WPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF RundumschlagWPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF Rundumschlag
Hendrik Lösch
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
Claudia Haußmann 🦋
 
EntwicklerCamp 2014 - DOTS reloaded
EntwicklerCamp 2014 - DOTS reloadedEntwicklerCamp 2014 - DOTS reloaded
EntwicklerCamp 2014 - DOTS reloaded
René Winkelmeyer
 
CDI
CDICDI
Software Metrics and Continuous Integration
Software Metrics and Continuous IntegrationSoftware Metrics and Continuous Integration
Software Metrics and Continuous Integration
Milena Reichel
 
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von AngrybirdCloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
AOE
 
Best Practices für TDD in JavaScript
Best Practices für TDD in JavaScriptBest Practices für TDD in JavaScript
Best Practices für TDD in JavaScript
Sebastian Springer
 

Ähnlich wie Advanced Refactoring Patterns (20)

Anforderungsanalyse und UML Grundlagen
Anforderungsanalyse und UML GrundlagenAnforderungsanalyse und UML Grundlagen
Anforderungsanalyse und UML Grundlagen
 
MVVM mit WPF
MVVM mit WPFMVVM mit WPF
MVVM mit WPF
 
react-de.pdf
react-de.pdfreact-de.pdf
react-de.pdf
 
AdvancedTdd
AdvancedTddAdvancedTdd
AdvancedTdd
 
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreHands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
 
Testgetriebene Softwareentwicklung
Testgetriebene SoftwareentwicklungTestgetriebene Softwareentwicklung
Testgetriebene Softwareentwicklung
 
Große Applikationen mit AngularJS
Große Applikationen mit AngularJSGroße Applikationen mit AngularJS
Große Applikationen mit AngularJS
 
Automatisiertes webauftritt testen
Automatisiertes webauftritt testenAutomatisiertes webauftritt testen
Automatisiertes webauftritt testen
 
Einführung in Clean Code mit .NET - Teil 1
Einführung in Clean Code mit .NET - Teil 1Einführung in Clean Code mit .NET - Teil 1
Einführung in Clean Code mit .NET - Teil 1
 
Implementierung der Knowledge Engineering Workbench in myCBR
Implementierung der Knowledge Engineering Workbench in myCBRImplementierung der Knowledge Engineering Workbench in myCBR
Implementierung der Knowledge Engineering Workbench in myCBR
 
Metaprogrammierung und Reflection
Metaprogrammierung und ReflectionMetaprogrammierung und Reflection
Metaprogrammierung und Reflection
 
magnolia mit thymeleaf - ein agiler prozess-beschleuniger
magnolia mit thymeleaf - ein agiler prozess-beschleunigermagnolia mit thymeleaf - ein agiler prozess-beschleuniger
magnolia mit thymeleaf - ein agiler prozess-beschleuniger
 
W-JAX 2013 Spring Batch - Performance und Skalierbarkeit
W-JAX 2013 Spring Batch - Performance und SkalierbarkeitW-JAX 2013 Spring Batch - Performance und Skalierbarkeit
W-JAX 2013 Spring Batch - Performance und Skalierbarkeit
 
WPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF RundumschlagWPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF Rundumschlag
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 
EntwicklerCamp 2014 - DOTS reloaded
EntwicklerCamp 2014 - DOTS reloadedEntwicklerCamp 2014 - DOTS reloaded
EntwicklerCamp 2014 - DOTS reloaded
 
CDI
CDICDI
CDI
 
Software Metrics and Continuous Integration
Software Metrics and Continuous IntegrationSoftware Metrics and Continuous Integration
Software Metrics and Continuous Integration
 
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von AngrybirdCloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
 
Best Practices für TDD in JavaScript
Best Practices für TDD in JavaScriptBest Practices für TDD in JavaScript
Best Practices für TDD in JavaScript
 

Mehr von Hendrik Lösch

Why (most) softwareprojects fail silently
Why (most) softwareprojects fail silentlyWhy (most) softwareprojects fail silently
Why (most) softwareprojects fail silently
Hendrik Lösch
 
We (don't) need a software architect!?!
We (don't) need a software architect!?!We (don't) need a software architect!?!
We (don't) need a software architect!?!
Hendrik Lösch
 
Restrukturierung einer industriellen Großapplikation
Restrukturierung einer industriellen GroßapplikationRestrukturierung einer industriellen Großapplikation
Restrukturierung einer industriellen Großapplikation
Hendrik Lösch
 
Vom Monolith zum Modulith
Vom Monolith zum ModulithVom Monolith zum Modulith
Vom Monolith zum Modulith
Hendrik Lösch
 
Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Der Software auf den Zahn gefühlt - Einstieg in die ArchitekturbewertungDer Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Hendrik Lösch
 
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
Hendrik Lösch
 
Software ist was du draus machst!
Software ist was du draus machst!Software ist was du draus machst!
Software ist was du draus machst!
Hendrik Lösch
 
Modular mit .NET
Modular mit .NETModular mit .NET
Modular mit .NET
Hendrik Lösch
 
.NET zu .NET Core
.NET zu .NET Core.NET zu .NET Core
.NET zu .NET Core
Hendrik Lösch
 
Workshop Vue js
Workshop Vue jsWorkshop Vue js
Workshop Vue js
Hendrik Lösch
 
Migrationsstrategien
MigrationsstrategienMigrationsstrategien
Migrationsstrategien
Hendrik Lösch
 
Einstieg in das Vueniverse
Einstieg in das VueniverseEinstieg in das Vueniverse
Einstieg in das Vueniverse
Hendrik Lösch
 
Survivalkit für Codehausmeister
Survivalkit für CodehausmeisterSurvivalkit für Codehausmeister
Survivalkit für Codehausmeister
Hendrik Lösch
 
Confessions of a Codehausmeister
Confessions of a CodehausmeisterConfessions of a Codehausmeister
Confessions of a Codehausmeister
Hendrik Lösch
 
Hey, wie geht es dir?
Hey, wie geht es dir?Hey, wie geht es dir?
Hey, wie geht es dir?
Hendrik Lösch
 
Clean mit visual studio
Clean mit visual studioClean mit visual studio
Clean mit visual studio
Hendrik Lösch
 
Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018
Hendrik Lösch
 
Der Healthcheck für Softwareprojekte
Der Healthcheck für SoftwareprojekteDer Healthcheck für Softwareprojekte
Der Healthcheck für Softwareprojekte
Hendrik Lösch
 
Ionic 3
Ionic 3Ionic 3
Ionic 2 - Hybridapps auf Steroiden
Ionic 2 - Hybridapps auf SteroidenIonic 2 - Hybridapps auf Steroiden
Ionic 2 - Hybridapps auf Steroiden
Hendrik Lösch
 

Mehr von Hendrik Lösch (20)

Why (most) softwareprojects fail silently
Why (most) softwareprojects fail silentlyWhy (most) softwareprojects fail silently
Why (most) softwareprojects fail silently
 
We (don't) need a software architect!?!
We (don't) need a software architect!?!We (don't) need a software architect!?!
We (don't) need a software architect!?!
 
Restrukturierung einer industriellen Großapplikation
Restrukturierung einer industriellen GroßapplikationRestrukturierung einer industriellen Großapplikation
Restrukturierung einer industriellen Großapplikation
 
Vom Monolith zum Modulith
Vom Monolith zum ModulithVom Monolith zum Modulith
Vom Monolith zum Modulith
 
Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Der Software auf den Zahn gefühlt - Einstieg in die ArchitekturbewertungDer Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
 
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
 
Software ist was du draus machst!
Software ist was du draus machst!Software ist was du draus machst!
Software ist was du draus machst!
 
Modular mit .NET
Modular mit .NETModular mit .NET
Modular mit .NET
 
.NET zu .NET Core
.NET zu .NET Core.NET zu .NET Core
.NET zu .NET Core
 
Workshop Vue js
Workshop Vue jsWorkshop Vue js
Workshop Vue js
 
Migrationsstrategien
MigrationsstrategienMigrationsstrategien
Migrationsstrategien
 
Einstieg in das Vueniverse
Einstieg in das VueniverseEinstieg in das Vueniverse
Einstieg in das Vueniverse
 
Survivalkit für Codehausmeister
Survivalkit für CodehausmeisterSurvivalkit für Codehausmeister
Survivalkit für Codehausmeister
 
Confessions of a Codehausmeister
Confessions of a CodehausmeisterConfessions of a Codehausmeister
Confessions of a Codehausmeister
 
Hey, wie geht es dir?
Hey, wie geht es dir?Hey, wie geht es dir?
Hey, wie geht es dir?
 
Clean mit visual studio
Clean mit visual studioClean mit visual studio
Clean mit visual studio
 
Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018
 
Der Healthcheck für Softwareprojekte
Der Healthcheck für SoftwareprojekteDer Healthcheck für Softwareprojekte
Der Healthcheck für Softwareprojekte
 
Ionic 3
Ionic 3Ionic 3
Ionic 3
 
Ionic 2 - Hybridapps auf Steroiden
Ionic 2 - Hybridapps auf SteroidenIonic 2 - Hybridapps auf Steroiden
Ionic 2 - Hybridapps auf Steroiden
 

Advanced Refactoring Patterns

  • 5. Refactoring bezeichnet in der Software-Entwicklung die manuelle oder automatisierte Strukturverbesserung von Quelltexten unter Beibehaltung des beobachtbaren Programmverhaltens. Dabei sollen die Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich zu senken. Quelle: https://de.wikipedia.org/wiki/Refactoring
  • 6. …is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring. refactoring.com
  • 7. Add Parameter Introduce Class Annotation Replace Conditional with Polymorphism Change Bidirectional Association to Unidirectional Introduce Expression Builder Replace Constructor with Factory Method Change Reference to Value Introduce Foreign Method Replace Data Value with Object Change Unidirectional Association to Bidirectional Introduce Gateway Replace Delegation With Hierarchy Change Value to Reference Introduce Local Extension Replace Delegation with Inheritance Collapse Hierarchy Introduce Named Parameter Replace Dynamic Receptor with Dynamic Method Definition Consolidate Conditional Expression Introduce Null Object Replace Error Code with Exception Consolidate Duplicate Conditional Fragments Introduce Parameter Object Replace Exception with Test Decompose Conditional Isolate Dynamic Receptor Replace Hash with Object Duplicate Observed Data Lazily Initialized Attribute Replace Inheritance with Delegation Dynamic Method Definition Move Eval from Runtime to Parse Time Replace Loop with Collection Closure Method Eagerly Initialized Attribute Move Field Replace Magic Number with Symbolic Constant Encapsulate Collection Move Method Replace Method with Method Object Encapsulate Downcast Parameterize Method Replace Nested Conditional with Guard Clauses Encapsulate Field Preserve Whole Object Replace Parameter with Explicit Methods Extract Class Pull Up Constructor Body Replace Parameter with Method Extract Interface Pull Up Field Replace Record with Data Class Extract Method Pull Up Method Replace Subclass with Fields Extract Module Push Down Field Replace Temp with Chain Extract Subclass Push Down Method Replace Temp with Query Extract Superclass Recompose Conditional Replace Type Code with Class Extract Surrounding Method Remove Assignments to Parameters Replace Type Code with Module Extension Extract Variable Remove Control Flag Replace Type Code With Polymorphism Form Template Method Remove Middle Man Replace Type Code with State/Strategy Hide Delegate Remove Named Parameter Replace Type Code with Subclasses Hide Method Remove Parameter Self Encapsulate Field Inline Class Remove Setting Method Separate Query from Modifier Inline Method Remove Unused Default Parameter Split Temporary Variable Inline Module Rename Method Substitute Algorithm Inline Temp Replace Abstract Superclass with Module Introduce Assertion Replace Array with Object refactoring.com
  • 8. “Code without tests is bad code. It doesn't matter how well written it is; it doesn't matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse.”
  • 12. 1. Quellcode einchecken. 2. Einen Überblick darüber verschaffen was geändert werden soll. 3. Mindestens einen Test schreiben der das bestehende Verhalten charakterisiert. 4. Refaktorisieren 5. Prüfen ob sich das Verhalten verändert hat.
  • 13. Situationen „Ich weiß nicht was mein Code macht, soll diesen Zustand aber ändern.“ Vorgehen Wir schreiben einen Test ohne Asserts und sehen uns anhand der Codeabdeckung an was passiert.
  • 14. Situationen „Ich will das mein Code sich nach den Änderungen so verhält wie vorher.“ Vorgehen Man schreibt oder generiert einen oder mehrere Tests um das Verhalten zu prüfen.
  • 16. Situationen „Ich muss Interna einer Klasse manipulieren um etwas testen zu können, will dies aber nur für die Tests tun.“
  • 19. Situationen „Wir haben keine Zeit für umfassende Refactorings.“ „Ich möchte Code testgetrieben in einer untestbaren Umgebung umsetzen.“ „Ich kann das Problem durch reines Hinzufügen von Code lösen.“
  • 23. Situationen „Ich muss eine vorhandene Schnittstelle ändern, möchte das Verhalten aber nicht unvorhergesehen schädigen.“
  • 29. Situationen „Ich habe eine Klasse/Methode die viel zu komplex ist.“ Vorgehen Wir lagern komplexe Methoden in eigene Klassen aus und brechen sie dort in weitere Methoden auf.
  • 30. ?!?
  • 33. Situationen „Ich muss ein altes System ablösen, es ist aber so komplex, dass ich dies nicht mit einen Mal tun kann. “ Vorgehen Wir bauen das neue System als Sprouts, ziehen schrittweise die Funktionalität aus dem alten und entfernen all die Teile die nicht mehr im alten gebraucht werden.
  • 41. Quelle: https://martinfowler.com/bliki/RefactoringMalapropism.html Refactoring • Kleine lokale Änderungen. • Schnelle Anpassungen mit geringen Auswirkungen auf andere. • Können ohne größere Absprache durchgeführt werden. • Keine tiefgreifenden architekturellen Anpassungen in bestehendem Code. Restructuring • Großflächige architekturelle Anpassungen die sich auf die Gesamtapplikation auswirken können. • Können andere Entwickler behindern. • Sollten nicht ohne Absprache und Planung durchgeführt werden.

Hinweis der Redaktion

  1. Die größten Probleme sind: Ich kann nicht testen, da ich Abhängigkeiten nicht los werde. Die Vorbedingungen sind so komplex, dass es nicht möglich ist sie zuverlässig für jeden Test aufzusetzen. Der gleiche Code kommt an unterschiedlichen Stellen in der Anwendung vor und müsste zusammen gefasst werden.
  2. Vorgehen Wir schaffen eine zentralisierte Zugriffsmodifikation die nur den Tests zur Verfügung steht.
  3. Vorteile Kann untestbaren Code testbar machen. Macht Tests robuster gegenüber Änderungen an der Implementierung Nachteile Wird die Implementierung geändert muss auch der Accessor angepasst werden. Tests können fehleranfällig sein, da nebenläufige Abhängigkeiten nicht betrachtet werden.
  4. Vorgehen Wir fügen den zusätzlichen Code als eigene Klasse oder Methode hinzu.
  5. Vorteile Schnell einsetzbar wenn nicht viele Abhängigkeiten bestehen Leicht zu testen Nachteile Kann langfristig zu unübersichtlichem Code führen Keine Verbesserung der Gesamtsituation Evtl. Verletzung von Seperation of Concernce & DRY Wenn Sprouts falsch verwendet werden induzieren sie Abhängigkeiten
  6. Vorgehen Wir schaffen zunächst einen Clone, nutzen diesen an einer Stelle, passen ihn an und migrieren anschließend alle anderen Stellen zur neuen Version. Abschließend wird die alte Version entfernt.
  7. Vorteile Erlaubt es Veränderungen in kleinen Schritten und lokal begrenzt vorzunehmen. Nachteile Kann das Laufzeitverhalten negativ beeinflussen. Bedeutet einen gesteigerten Test und Implementierungsaufwand. Kann den Code unübersichtlich machen.
  8. ExPorterDB1 Vorgehen Wir verschieben eine Methode in eine Klasse. Behalten den Rahmen der Methode aber zerlegen sie in viele private Methoden.
  9. Vorteile Kann untestbaren Code testbar machen. Hilft das Verständnis für einen Vorgang zu verbessern. Kann bereits die Architektur verbessern. Nachteile Kann den internen Status der Klasse ändern wenn mit anderen Klassenmembern vermischt -> unbedingt eigene Klasse anlegen.
  10. Vorteile Erlaubt es Systeme iterativ inkrementell zu ersetzen. Altes wie neues System werden zeitgleich gepflegt. Nachteile Wenn es zu lange dauert, veraltet das neue System ebenfalls. Die Grenzen müssen klar definiert sein, ansonsten behindern sich die Systeme gegenseitig.