Design Patterns & Refactoring Introduction to Refactoring - - PowerPoint PPT Presentation

design patterns refactoring
SMART_READER_LITE
LIVE PREVIEW

Design Patterns & Refactoring Introduction to Refactoring - - PowerPoint PPT Presentation

Design Patterns & Refactoring Introduction to Refactoring Oliver Haase HTWG Konstanz Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 1 / 9 What is Refactoring? Definition (of the noun) A change made to the internal


slide-1
SLIDE 1

Design Patterns & Refactoring

Introduction to Refactoring Oliver Haase

HTWG Konstanz

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 1 / 9

slide-2
SLIDE 2

What is Refactoring?

Definition (of the noun)

A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable

  • behavior. (Martin Fowler)

Definition (of the verb)

To restructure software by applying a series of refactorings without changing its observable behavior. (Martin Fowler)

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 2 / 9

slide-3
SLIDE 3

Definition – Key Points

make software structure easier: compare with performance

  • ptimizations that

don’t change functionality, but usually make software harder to understand!

without changing behavior: user (end user or other software) cannot tell that implementation has changed.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 3 / 9

slide-4
SLIDE 4

Definition – Key Points

make software structure easier: compare with performance

  • ptimizations that

don’t change functionality, but usually make software harder to understand!

without changing behavior: user (end user or other software) cannot tell that implementation has changed. No Refactoring Without Thorough Unit Tests!

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 3 / 9

slide-5
SLIDE 5

Metaphor of the Two Hats

Software development should consist of distinguishable phases of addition

  • f new functionality and refactoring:

When adding new functionality, don’t refactor existing code. When refactoring, don’t change existing behavior. A developer might swap hats very frequently, but should always be aware of which hat she is currently wearing.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 4 / 9

slide-6
SLIDE 6

Why Should You Refactor?

Without refactoring, code will decay

→ more often than not, code additions lead to redundancy! → refactoring as a means to periodically clean up code

Refactoring makes the code easier to understand Refactoring helps you find bugs Refactoring helps you program faster

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 5 / 9

slide-7
SLIDE 7

When Should You Refactor?

Should you schedule two weeks of refactoring every other month of development?

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 6 / 9

slide-8
SLIDE 8

When Should You Refactor?

Should you schedule two weeks of refactoring every other month of development? You don’t decide to refactor, you refactor because you want to do something else, and refactoring helps you do the other thing.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 6 / 9

slide-9
SLIDE 9

The Rule of Three

Three strikes and you refactor.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 7 / 9

slide-10
SLIDE 10

The Rule of Three

Three strikes and you refactor.

1 Just do it. 2 Wince at duplication, duplicate anyway. 3 Refactor. Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 7 / 9

slide-11
SLIDE 11

What Do I Tell My Manager?

Many managers don’t appreciate refactoring per se but: refactoring is a necessary part of the development process

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 8 / 9

slide-12
SLIDE 12

What Do I Tell My Manager?

Many managers don’t appreciate refactoring per se but: refactoring is a necessary part of the development process ⇓ Don’t tell.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 8 / 9

slide-13
SLIDE 13

Problems with Rectoring

Databases: Data schemas that applications are tightly coupled to are hard to change → Refactoring of databases is an own research area. Changing Interfaces:

Minimize published interfaces, i.e. those whose users you cannot change. Don’t publish interfaces prematurely. Loosen code ownership so that unpublished interfaces can be changed.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 9 / 9