lecture 38: refactoring
Post on 24-Feb-2016
20 Views
Preview:
DESCRIPTION
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