1 Software Maintenance and Evolution CSSE 575: Session 3, Part 4 Big Refactorings Steve Chenoweth Office Phone: (812) 877-8974 Cell: (937) 657-3885 Email:

Slides:



Advertisements
Similar presentations
4. Object-Oriented Programming Procedural programming Structs and objects Object-oriented programming Concepts and terminology Related keywords.
Advertisements

Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
1 Copyright 1998 by Dragos Manolescu and Joseph W. Yoder Building Frameworks With Patterns “An Active Object-Model For A Dynamic Web-Based Application”
© 2010 Shawn A. Bohner Software Construction and Evolution - CSSE 375 Even more Bad Smells in Code Shawn & Steve Q1 Shawn & Steve Hint 
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 2 Composing Methods Steve Chenoweth Office Phone: (812) Cell: (937)
Gregor Gisler-Merz BrownBag Session Refactoring.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
REFACTORING. What is refactoring ? In refactoring, you start with the basic code and make it better. Change the internal structure of the existing code.
SOLID Object Oriented Design Craig Berntson
Lectures 17 and 18 A Refactoring Micro-Example FOR0383 Software Quality Assurance 5/16/20151Dr Andy Brooks Refactoring is really easy using this tool.
Software Construction and Evolution - CSSE 375 Bad Smells in Code Shawn Bohner & Steve Chenoweth.
1 Software Maintenance and Evolution CSSE 575: Session 9, Part 2 A Model for Evolutionary Growth Steve Chenoweth Office Phone: (812) Cell: (937)
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 3 Moving Features Between Objects Steve Chenoweth Office Phone: (812) Cell: (937)
1 Software Maintenance and Evolution CSSE 575: Session 1, Part 4 Even more Bad Smells in Code Steve Chenoweth Office Phone: (812) Cell: (937)
1 Software Maintenance and Evolution CSSE 575: Session 6, Part 4 Breaking Dependencies Steve Chenoweth Office Phone: (812) Cell: (937)
1 Software Maintenance and Evolution CSSE 575: Session 1, Part 1 Course Introduction Steve Chenoweth Office Phone: (812) Cell: (937)
1 Software Maintenance and Evolution CSSE 575: Session 8, Part 3 Predicting Bugs Steve Chenoweth Office Phone: (812) Cell: (937)
Introduction to Refactoring Excerpted from ‘What is Refactoring?’ by William C. Wake and Refactoring: Improving the Design of Existing Code by Martin Fowler.
XP and Refactoring David Talby. Development Methodologies The Software Crisis – 84% of software projects are not on time – 31% of software projects never.
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
GENERAL CONCEPTS OF OOPS INTRODUCTION With rapidly changing world and highly competitive and versatile nature of industry, the operations are becoming.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
1 Software Construction and Evolution - CSSE 375 Exception Handling – Logging & Special Situations Steve Chenoweth Office: Moench Room F220 Phone: (812)
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
Refactoring. Mathematics: Factor ● fac·tor – One of two or more quantities that divides a given quantity without a remainder, e.g., 2 and 3 are factors.
Refactoring Improving the structure of existing code Refactoring1.
1 Software Construction and Evolution - CSSE 375 Exception Handling - Principles Steve Chenoweth, RHIT Above – Exception handling on the ENIAC. From
CSSE 374: More GRASP’ing for Object Responsibilities
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 1 Simplifying Conditionals Steve Chenoweth Office Phone: (812) Cell: (937)
Refactoring1 Improving the structure of existing code.
B065: PROGRAMMING Sub Procedures I. Starter  Identify the separate tasks to be performed in the programming task below (break it down into numbered sections).
Introduction to Refactoring Jim Cooper Falafel Software.
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 and such ● (Side note) Specialization ● Key terms ● Abstraction, state, persistence and association and their relationship to software development.
Refactoring. Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative.
Refactoring 2. Admin Blackboard Quiz Acknowledgements Material in this presentation was drawn from Martin Fowler, Refactoring: Improving the Design of.
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.
1 Software Construction and Evolution - CSSE 375 Exception Handling – Chaining & Threading Steve Chenoweth Office: Moench Room F220 Phone: (812)
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 1 Refactoring Principles Steve Chenoweth Office Phone: (812) Cell: (937)
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Construction and Evolution - CSSE 375 Making Method Calls Simpler Shawn and Steve Below – “Be the character!” The late acting teacher Lee Strasberg.
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 3 Dealing with Generalization Steve Chenoweth Office Phone: (812) Cell: (937)
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
Refactoring Advanced Software Engineering Dr Nuha El-Khalili.
Software Construction and Evolution CSSE 375: Course Introduction Steve Chenoweth Office: Meonch Room F220 Phone: (812)
Refactoring. Mathematics: Factor ● fac·tor – One of two or more quantities that divides a given quantity without a remainder, e.g., 2 and 3 are factors.
Refactoring1 Improving the structure of existing code.
Pertemuan 12 Refactoring Mata kuliah: T0144 – Advanced Topics in Software Engineering Tahun: 2010.
Refactoring. 2 Process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal.
CSSE 375 Organizing Data – Part 1 Shawn and Steve Q1.
Software Construction and Evolution - CSSE 375 Dealing with Generalization Steve and Shawn Left – In the 1990 movie “The Freshman,” Matthew Broderick,
ICONFINDER ICONFINDER Founded Django based web application -PostgreSQL -Elasticsearch -Amazon Elastic Compute.
Principles and examples
Steve Chenoweth Office Phone: (812) Cell: (937)
Steve Chenoweth Office Phone: (812) Cell: (937)
Software Engineering Modern Approaches Chapter 24. Refactoring.
Steve Chenoweth Office Phone: (812) Cell: (937)
Software Maintenance and Evolution CSSE 575: Session 1, Part 1 Course Introduction Steve Chenoweth Office Phone: (812) Cell: (937)
Steve Chenoweth Office Phone: (812) Cell: (937)
Steve Chenoweth, RHIT Ch 12 in Fowler
Code Smells 1.
Improving the structure of existing code
Systems Analysis – ITEC 3155 Modeling System Requirements – Part 2
Refactoring Types Blake Duncan.
Refactoring.
ANALYSIS REFACTORING WITH TOOLS
Refactoring.
Presentation transcript:

1 Software Maintenance and Evolution CSSE 575: Session 3, Part 4 Big Refactorings Steve Chenoweth Office Phone: (812) Cell: (937) hulman.edu Above – a poster for refactoring, from ter ter

2 These are higher level… These likely take a team, in order to do them systematically. Include: – Tease apart inheritance – Convert procedural design to objects – Separate domain from presentation – Extract hierarchy Right – Hierarchy in action – the hat you wear in England depends on your position. From i/coronets_and_hierarchy.htm. i/coronets_and_hierarchy.htm

3 Tease apart inheritance If you have two parallel sub- hierarchies, they probably contain duplicated code Need to extract what really doesn’t belong, leaving the common parts in a single hierarchy.

4 Convert procedural design to objects Turn the data records into objects Break up the behavior Move the behavior into the objects

5 Separate domain from presentation This is like Model-View- Controller. Not so easy to do, in a system where that strategy was not taken from the start.

6 Extract hierarchy Have a class doing too much work – Partly through many conditional statements Create a hierarchy of classes in which each subclass represents a special case

7 Consideration of levels The Infosys pdf you read suggested that refactoring applies to many different levels. See services/white-papers/Documents/refactoring.pdfhttp:// services/white-papers/Documents/refactoring.pdf Included: Structural Code clean-up Code standards User interface Database clean-up Database design/schema Architecture

8 Consideration of purpose In your own journals, some of you suggested refactoring may be for reasons other than code simplification: – Achieving some Quality Attribute goal, like – Performance Security – Getting rid of some other kind of smell, like – The new people never understand this part. This part is always being changed. 8

9 What’s built-in? Check out the list of “Refactoring commands” for C# /Visual Studio 2013 ! – From us/library/719exd8s.aspx. us/library/719exd8s.aspx Included: Extract Method Refactoring (C#) Rename Refactoring (C#) Encapsulate Field Refactoring (C#) Extract Interface Refactoring (C#) Remove Parameters Refactoring (C#) Reorder Parameters Refactoring (C#) 9

10 Where we have Been so far… Refactoring – Bad Code Smells – Composing Methods – Moving Features between Objects – Organizing Data – Simplifying Conditional Expressions – Making Method Calls Simpler – Dealing with Generalization – Big Refactorings These principles will serve you in constructing and evolving software systems

11 Perfect Midterm Questions 1.Here’s a sample of some code. What refactoring would you use on it, and why. 2.What are the conditions in the lifecycle that favor spending more time refactoring? 3.Find two pairs of refactoring rules which appear to be opposite advice. Explain what nuances of a situation would favor each. 11

12 Moving up from “Shu” to “Ha” In the refactoring article you read for today, at /rotten-code.html, were you convinced that the problem of refactoring was not easily decomposable into just doing obvious steps? /rotten-code.html 12

13 And from Ha to Aha Last week we talked about Lambdas How about as a way to refactor? – See example-refactoring-code/ example-refactoring-code/ – Concept – Private handling methods can get “handed out” as well as “handed in” – A perfect way of feeding specifics to frameworks? 13