1 / 14

Lecture 38: Refactoring

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

theta
Download Presentation

Lecture 38: Refactoring

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 38:Refactoring CSC 395 – Software Engineering

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

  3. RealSoftware Development • 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

  4. RealSoftware, Take 2 • 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

  5. Whoever Smelled It... • 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

  6. More Bad Smells • 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

  7. Get Me Some Deodorant! • 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"

  8. 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 • Finish work early and ease into any deadlines

  9. 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 • Refactorcode before or after each deadline • Code quickly then refactor before deadlines in agile • Start iteration refactoring code in iterative methods

  10. What Could Go Wrong? • 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)

  11. What Do We Need • 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

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

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

  14. For Next Lecture • 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

More Related