lecture 38: refactoring csc 395 – software engineering

14
38: REFACTORIN G CSC 395 – Software Engineering

Upload: marilynn-jordan

Post on 31-Dec-2015

220 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: LECTURE 38: REFACTORING CSC 395 – Software Engineering

LECTURE 38:REFACTORING

CSC 395 – Software Engineering

Page 2: 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

Page 3: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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

Page 4: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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

Page 5: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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...

Page 6: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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

Page 7: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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!

Page 8: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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

Page 9: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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

Page 10: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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?

Page 11: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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

Page 12: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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

patterns, etc.

What We Really Need

Page 13: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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

Page 14: LECTURE 38: REFACTORING CSC 395 – Software Engineering

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