1. LECTURE 38: REFACTORING CSC 395 – Software Engineering

2.  Comprehensive  Comprehensive requirements developed or added workable  Working from these, create workable design  Class design tested & all defect fixes reviewed  Complete  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

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

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

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

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

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

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

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

10.  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?

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

12.  Definitely require good set of test cases  Run tests before refactoring started  Remove redundant code, add design patterns, etc. What We Really Need

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

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