lecture 38: refactoring

Post on 24-Feb-2016

20 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Lecture 38: Refactoring. CSC 395 – Software Engineering. Software Being Developed. Comprehensive requirements developed or added Working from these, create workable design Class design tested & all defect fixes reviewed Complete test suite check for range of bugs - PowerPoint PPT Presentation

TRANSCRIPT

LECTURE 38:REFACTORING

CSC 395 – Software Engineering

Comprehensive requirements developed or added

Working from these, create workable design Class design tested & all defect fixes reviewed

Complete test suite check for range of bugs 100% path coverage & more for complex methods Code reviews used on every line of code in system

Integration & validation tests on completed code Last few days spent completing documentation

Software Being Developed

Develop good set of requirements with client Once “complete”, client changes mind 5

times Solid design developed from these

requirements But design was only using revision 3 of

requirements Some issues uncaught until code monkeys

started Coding takes much, much longer than

planned All-nighters needed for final push over last

week Due to lack of time, final bugs fixed via

patch Documentation good, but not always

complete

Real Software Development

Develop comprehensive set of requirements Problem known, system reuses existing

code base Nearly complete design developed

If even remotely feasible, existing classes used

Design is complete, but some rough edges remain

Coding done quickly, but needs to be quick Mashes up existing classes for new purpose Lots of having to fit square pegs into round

holes Comments good, but don't always fit

program

Real Software, Take 2

Code occasionally gets "bad smell" Code duplicated in methods and classes Wrote and now must use ginormous method or

class 7+ parameters used by a single method Simple class now serves multiple purposes "Shotgun surgery" with requires many little

changes Mostly call methods in other class "feature envy" Variables not independent, but always used

together No polymorphism, instead uses large switch/if-

else

Whoever Smelled It...

Only one subclass possible for an abstract class

Code only to support non-existent feature(s) Field is temporary; value not used across

methods Coupling too close or "inappropriate

intimacy" Classes work identically, but signatures

differ No use of inherited methods or "Refused

bequest" Comments needed to explain lousy code

More Bad Smells

Nothing ever perfect the first time Getting the details right often takes

multiple passes Even harder without full picture of what will

be done Ugly code often results as deadlines

approach "Get it done right" becomes "Get it done

right now"

Get Me Some Deodorant!

Bad smells always occur for variety of reasons But ugly code does need not linger forever Refactoring important to eliminate these

problems Finish work early and ease into any

deadlines

Vital Part of Project

Bad smells always occur for variety of reasons But ugly code does need not linger forever Refactoring important to eliminate these

problems Refactor code before or after each

deadline Code quickly then refactor before deadlines

in agile Start iteration refactoring code in iterative

methods

Vital Part of Project

Refactoring creates opportunities for mayhem Intentionally changing code that works & is

used Modifications could accidentally add

regression faults Must respect assumptions made by other

code (Requires that these assumptions are

known)

What Could Go Wrong?

Good documentation crucial to this process Method should state preconditions before

called Expectations of results specified as

postcondition Invariants list as relationships between

fields Comments kept up-to-date as coding

continues Refactoring works provided stay within

limits

What Do We Need

Definitely require good set of test cases Run tests before refactoring started Remove redundant code, add design

patterns, etc.

What We Really Need

Definitely require good set of test cases Re-run tests after refactoring (or close

enough) If test fails, fix the refactored code

Add comments describing the missing details

If all tests pass, continue progressing Doing it right the first time would have

been faster… … but still a lot better than non-refactored

code All roads lead to multiple passes

What We Really Need

Rehearse (& re-rehearse) group’s presentation For each of your groups, this is vital part of

project Show what you learned about oral

communication Show value of your system & sell us on

your solution Do not bore rest of class

For Next Lecture

top related