LECTURE 38: REFACTORING CSC 395 – Software Engineering.

Slides:



Advertisements
Similar presentations
Test-First Programming. The tests should drive you to write the code, the reason you write code is to get a test to succeed, and you should only write.
Advertisements

12-Dec-14 Refactoring IV. Previously discussed bad smells Duplicated code — and other forms of redundancy Long method — use short methods that delegate.
Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
Test-Driven Development and Refactoring CPSC 315 – Programming Studio.
Computer Engineering 203 R Smith Project Tracking 12/ Project Tracking Why do we want to track a project? What is the projects MOV? – Why is tracking.
General OO Concepts and Principles CSE301 University of Sunderland Harry R. Erwin, PhD.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
SOLID Object Oriented Design Craig Berntson
Software Construction and Evolution - CSSE 375 Bad Smells in Code Shawn Bohner & Steve Chenoweth.
Software Engineering and Design Principles Chapter 1.
Six compound procedures and higher-order procedures.
Test-Driven Development and Refactoring Project 3 Lecture 1 CPSC 315 – Programming Studio Fall 2009.
1 Software Testing and Quality Assurance Lecture 28 – Testing Class Hierarchies.
Individuals and interactions
Individuals and interactions
Introduction to Refactoring Excerpted from ‘What is Refactoring?’ by William C. Wake and Refactoring: Improving the Design of Existing Code by Martin Fowler.
George Blank University Lecturer. REFACTORING Improving the Design of Existing Code Supplement to Ian Sommerville, Software Engineering, Chapter 20 Prepared.
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
CSC 395 – Software Engineering Lecture 21: Overview of the Term & What Goes in a Data Dictionary.
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
13-Jul-15 Refactoring II. Books Design Patterns is the classic book by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Basically a catalog.
Test Driven Development Derived from Dr. Fawcett’s notes Phil Pratt-Szeliga Fall 2009.
CSC 213 – Large Scale Programming. Today’s Goal  Learn Unified Process to design programs  Understand what are the “types” of Java classes  Methods.
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
CSC 395 – Software Engineering Lecture 34: Post-delivery Maintenance -or- What’s Worse than Being a Code Monkey?
© S. Demeyer, S. Ducasse, O. Nierstrasz Intro.1 1. Introduction Goals Why Reengineering ?  Lehman's Laws  Object-Oriented Legacy Typical Problems  common.
CSC 395 – Software Engineering Lecture 12: Reusability –or– Programming was Bjarne Again.
CSC 211 Introduction to Design Patterns. Intro to the course Syllabus About the textbook – Read the introduction and Chapter 1 Good attendance is the.
1 Software Process Models-ii Presented By; Mehwish Shafiq.
Refactoring Improving the structure of existing code Refactoring1.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
CSC 213 – Large Scale Programming. Today’s Goal  Improve design skills to make usable designs  Noun extraction & UML class diagram reviewed  Connections.
Improving the Quality of Existing Code Svetlin Nakov Telerik Corporation
Refactoring1 Improving the structure of existing code.
Lazy Contemplative Always Using Imagination Most Important Trait.
A Practical Guide To Unit Testing John E. Boal TestDrivenDeveloper.com.
1 Design and Integration: Part 2. 2 Plus Delta Feedback Reading and lecture repeat Ambiguous questions on quizzes Attendance quizzes Boring white lecture.
Incremental Design Why incremental design? Goal of incremental design Tools for incremental design  UML diagrams  Design principles  Design patterns.
Software Engineering CS3003 Lecture 4 Code bad smells and refactoring.
Refactoring. Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative.
REFACTORINGREFACTORING. Realities Code evolves substantially during development Requirements changes 1%-4% per month on a project Current methodologies.
Module 3. Smells Between Classes Course: Refactoring.
Extreme Programming Based on and
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 1 Refactoring Principles Steve Chenoweth Office Phone: (812) Cell: (937)
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
(1) Test Driven Development Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu.
Refactoring1 Improving the structure of existing code.
Refactoring Agile Development Project. Lecture roadmap Refactoring Some issues to address when coding.
Pertemuan 12 Refactoring Mata kuliah: T0144 – Advanced Topics in Software Engineering Tahun: 2010.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Refactoring. DCS – SWC 2 Refactoring ”A change made to the internal structure of software to make it easier to understand and cheaper to modify without.
Code Simplicity: Software Design In Open Source Projects Max Kanat-Alexander
TDD Unit tests from a slightly different point of view Katie Dwyer.
Principles and examples
Steve Chenoweth Office Phone: (812) Cell: (937)
Refactoring and Code Smells
Code Smells 1.
Improving the structure of existing code
Refactoring and Code Smells
Refactoring Types Blake Duncan.
Refactoring.
Refactoring and Code Smells
Agile Development – a new way of software development?
Refactoring.
Refactoring and Code Smells
Presentation transcript:

LECTURE 38: REFACTORING CSC 395 – Software Engineering

 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

 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