Introduction to Refactoring Jim Cooper Falafel Software.

Slides:



Advertisements
Similar presentations
Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
Advertisements

A practical guide John E. Boal TestDrivenDeveloper.com.
Test-Driven Development and Refactoring CPSC 315 – Programming Studio.
© 2010 Shawn A. Bohner Software Construction and Evolution - CSSE 375 Even more Bad Smells in Code Shawn & Steve Q1 Shawn & Steve Hint 
Abstraction Lecture-4. ADT example: London Underground Map.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
Software Construction and Evolution - CSSE 375 Bad Smells in Code Shawn Bohner & Steve Chenoweth.
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.
XP and Refactoring David Talby. Development Methodologies The Software Crisis – 84% of software projects are not on time – 31% of software projects never.
25-Jun-15 Refactoring III. General philosophy A refactoring is just a way of rearranging code Refactorings are used to solve problems If there’s no problem,
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
Chapter 6. 2 Objectives You should be able to describe: Function and Parameter Declarations Returning a Single Value Pass by Reference Variable Scope.
ASP.NET Programming with C# and SQL Server First Edition
Algorithm Programming Coding Advices Bar-Ilan University תשס " ו by Moshe Fresko.
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
Chapter 7 Designing Classes. Class Design When we are developing a piece of software, we want to design the software We don’t want to just sit down and.
Chapter 11 Introduction to Classes Intro to Computer Science CS1510, Section 2 Dr. Sarah Diesburg.
Refactoring Cristescu Marilena. Definitions Loose Usage: Reorganize a program(or something) As a noun: a change made to the internal structure of some.
A First Book of C++: From Here To There, Third Edition2 Objectives You should be able to describe: Function and Parameter Declarations Returning a Single.
Programming in Java Unit 2. Class and variable declaration A class is best thought of as a template from which objects are created. You can create many.
Software Refactoring Part I: Introduction Bartosz Walter Advanced Object-Oriented Design Lecture 5.
Sadegh Aliakbary Sharif University of Technology Spring 2012.
CSCI-383 Object-Oriented Programming & Design Lecture 13.
Refactoring Improving the structure of existing code Refactoring1.
17-Oct-15 Refactoring. 2 Refactoring is: restructuring (rearranging) code......in a series of small, semantics-preserving transformations (i.e. the code.
Refactoring (continued) Source: "Refactoring: Improving the Design of Existing Code", Martin Fowler.
Best Practices. Contents Bad Practices Good Practices.
Refactoring1 Improving the structure of existing code.
Refactoring Deciding what to make a superclass or interface is difficult. Some of these refactorings are helpful. Some research items include Inheritance.
Informatics 122 Software Design II
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.
Refactoring II Dealing with Polymorphism. Switch in Rental Switches on Movie! class Rental … public double getCharge() { double result = 0; switch (getMovie().getPriceCode()){
Module 3. Smells Between Classes Course: Refactoring.
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 1 Refactoring Principles Steve Chenoweth Office Phone: (812) Cell: (937)
M1G Introduction to Programming 2 5. Completing the program.
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 3 Dealing with Generalization Steve Chenoweth Office Phone: (812) Cell: (937)
M1G Introduction to Programming 2 3. Creating Classes: Room and Item.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
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.
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.
1 COS 260 DAY 12 Tony Gauvin. 2 Agenda Questions? 5 th Mini quiz –Chapter 5 40 min Assignment 3 Due Assignment 4 will be posted later (next week) –If.
CSSE 375 Organizing Data – Part 1 Shawn and Steve Q1.
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.
CSCE 240 – Intro to Software Engineering Lecture 3.
Catalog of Refactoring (1) Composing Methods. Code Smells Long methods Dubious temporary variables Dubious methods.
A (Very) Simple Example Consolidate duplicate conditional fragments if (isSpecialDeal()) { total = price * 0.95; send (); } else { total = price * 0.98;
Principles and examples
Steve Chenoweth Office Phone: (812) Cell: (937)
C++ coding standard suggestion… Separate reasoning from action, in every block. Hi, this talk is to suggest a rule (or guideline) to simplify C++ code.
Chapter 11 Object-Oriented Design
Refactoring and Code Smells
Objects First with Java
Refactoring III 27-Nov-18.
Code Smells 1.
Improving the structure of existing code
Refactoring and Code Smells
Refactoring III 25-Dec-18.
Refactoring.
Refactoring and Code Smells
Software Development Techniques
Refactoring.
Refactoring and Code Smells
Presentation transcript:

Introduction to Refactoring Jim Cooper Falafel Software

Refactoring Refactoring. Improving the Design of Existing Code Martin Fowler 2000, Addison-Wesley ISBN We will use that terminology, guidelines and naming

What is Refactoring? “Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure.” Term applies both to the process and the individual techniques

What is Refactoring? - 2 Each refactoring is a series of steps Each step is simple and small Minimises introduction of new bugs Unit tests used to verify changes Behavioural changes to a program are not refactorings

Why Refactor? Code is not for computers to read, it’s for us to read 90% of the lifetime of most software is in maintenance mode Source code must be easy for humans to read, understand and modify Refactoring helps make the code more usable by programmers

Aims of Refactoring Improved design Make code easier to understand Can use it on other people’s code Help find bugs Faster programming in the long term Formalise and name best practices Easier to talk about Reduce chaos in long-lived code

Opportunities for Refactoring When adding functionality Make adding new feature easier Keep refactoring separate, though When fixing a bug During a code review Pair programming Refactoring takes time Sneak it past managers

Refactoring Techniques Too many to look at all of them Will not discuss unit testing in detail Start with the main ones, and then browse the book looking at others No need to read the book cover to cover (it’s not that interesting)

Points to Note Refactoring relies heavily on having object oriented code Refactorings are usually more atomic than patterns, but some use patterns Often language dependent Refactoring book is very Java oriented We will cover converting to Delphi Not many refactorings use interfaces

Points to Note - 2 Many refactorings make use of other, simpler refactorings Some are opposites Use the one that makes your code easier to understand Can apply some mechanically It is possible to go too far!

Extract Method Probably the most used technique You should have done this many times yourself Identify code to reuse, or that is making a method too long, so we make a new method out of it Difference here is the formal definition of the process, and the guidelines for its use

Structure of Extract Method Name – Extract Method Summary – describes when to use You have a code fragment that can be grouped together Turn the fragment into a method whose name explains the purpose of the method

Structure of Extract Method - 2 Short code example Motivation Describes why the refactoring should be done, and also when it shouldn’t Mechanics Step by step instructions One or more longer examples, usually with discussion

Structure of Extract Method - 3 Motivation A method is too long A section of code needs a comment to explain it Short (well-named) methods easier to reuse and override Higher-level methods easier to read Good naming is key

Structure of Extract Method - 4 Mechanics Create a new method with a good name Copy extracted code to new method Deal with variables and parameters in the original method

Dealing with Variables Local variables only used in the extracted code can be copied to the new method One original variable modified Make the new method a function Several original variables modified Use var parameters Use other refactorings first

Dealing with Variables - 2 Replace Temp with Query Remove local variable, move expression to a method and call it each time the variable was used Split Temporary Variable Use a different local variable for each assignment

Structure of Extract Method - 5 Pass any original parameters used to the new method Compile Replace extracted code with method call Remove any local variables no longer used Compile and test Don’t forget to test!!

Extract Class Used when a class is violating the principle of separation of concerns Often the result of feature creep Can result from too many Extract Method refactorings Splits out related subset of data and methods into a new class May need to rename the old class if its duties have changed

Extract Class - 2 Normally need a reference to an object of the new class in the old one Leave the new class in the implementation section if only used internally Uses Move Field and Move Method refactorings to move elements of the new class across (test after each move)

Inline Class The opposite of Extract Class Applied when a class is doing too little Move fields and methods into a class that uses them (there won’t be many) Fowler humour : The last step of the refactoring reads “Hold a short, simple funeral service”

Move Method Moves a method from one class to another May change name in the new class Original class probably needs to refer to an instance of the new one If the method is declared in an ancestor or descendant class, may not be able to move it easily

Inline Temp Replace a local variable assigned to with a simple expression, with the expression Removing local variables can make other refactorings easier Local variable may be doing no harm, or may be there to avoid breaking the Law of Demeter Leave it there

Rename Method If the task of a method has changed, rename it to reflect the new duties Seems trivial, but is very important Bad naming defeats the whole purpose of encapsulation Code is confusing, in the worst case it can be completely misinterpreted

Replace Magic Number with Symbolic Constant Encapsulates a standard piece of programming advice Applies to strings etc, as well, of course This sort of refactoring useful when training new programmers

Replace Error Code with Exception If you don’t already do this, line up at the front for a slapping Code can be written assuming it works, and is therefore much easier to read Error handling code separated out

Encapsulate Field Needs to be modified for Delphi Replace Field with Property Replace a public field with a property Otherwise the Delphi Style Police will come and kick you around Use the Delphi naming convention Move field to private, rename with F Make a property named without the F

Self Encapsulate Field We might allow direct access to a field within a class, if field is private If field needs to be protected or better, or has side effects when used, then make it into a property Direct access in constructor, destructor and property accessor methods Use Replace Field with Property

Remove Control Flag Some people use a local variable as a control flag to break out of loops I’ve even seen goto used this way! Use Break, Continue and Exit instead

Replace Type Code with State/Strategy This refactoring introduces either the State or Strategy pattern Used when the class behaviour varies depending on some state value Lots of case statements are a giveaway Demo code

Finite State Machine This example is from ToD, with the kind permission of Julian Bucknall

Convert Refactorings to Delphi Use const instead of final To make an immutable class, make all the properties read only, and set their values in the constructor Query = Function Temporary variable = local variable Some refactorings cannot be applied e.g. garbage collection

When to Refactor – Bad Smells Kent Beck’s idea Combination of experience and intuition sometimes makes us feel code just isn’t right There are some indicators we can look for Bad Smells Have names and recommended treatments

Bad Smells Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery Feature Envy

Bad Smells - 2 Data Clumps Primitive Obsession Switch Statements Parallel Inheritance Hierachies Lazy Class Speculative Generality Data Class, Refused Bequest Comments

Problems Do not apply refactorings without thought for the consequences Threads Discipline is new, so not all problems found yet Databases Changing interfaces Designs difficult to refactor Code is beyond all help

Miscellaneous Still need upfront design, but can design for ease of refactoring Don’t make design too flexible Don’t make optimisation decisions before finding bottlenecks Refactor first, optimise after Tools exist for Java (some in JBuilder) and C#, but little for Delphi...

Refactoring in Delphi Until now! Diamondback has the following refactorings built in, with a promise of many more to follow Rename Extract Method Extract Resource String

Refactoring in Delphi - 2 In addition, the new refactoring engine makes possible some handy things which are not, strictly speaking, refactorings SyncEdit mode Find References Declare Variable Declare Field Import Namespace

Questions?

Thank You You can contact me further at