XP and Refactoring David Talby

Development Methodologies The Software Crisis – 84% of software projects are not on time – 31% of software projects never complete – Most software is buggy, unstable and insecure – Lack of repeatability (engineering) eXtreme Programming – For small projects: up to 12 people, 100 stories Rational Unified Process – For large projects: a “heavy-weight” process – A commercial product

Rational Unified Process By Rational, see rational.com/ruprational.com/rup Decompose large system to sub-systems – A team and development effort per system – Architects Team does overall design, sharing Five stages of each system’s life cycle – Business modeling, Requirements, Analysis & Design, Implementation, Test – Many artifacts are not code or tests Iterative Development Highly managed, highly automated process

eXtreme Programming By Kent Beck, see XProgramming.comXProgramming.com Embrace change Simplicity User involvement & rapid feedback Incremental pay-as-you-go design Test-first programming

The 12 XP Principles Planning Game Small Releases On-Site Customer Metaphor Simple Design 40-Hour Week Pair Programming Collective Ownership Testing Refactoring Continuous Integration Coding Standard

The XP Principles Develop by iterations of 1-3 weeks each: Plan (user stories) -> design (simplest!) -> test (unit tests) -> code (and refactor) Testing – Functional tests: in design phase – Unit tests as part of coding Continuous Integration Quality Work – Refactoring, 40-Hour Week

Refactoring Improving the design of existing code, without changing its observable behavior Here ’ s the Extract Method refactoring: After: void f() { … computeScore(); } computeScore(int[] a) { // code cut & pasted here } Before: void f(int[] a) { … // compute score score = initial_score; for (int i=0; i<a.length; i++) score += a[i] * delta; }

Why? Why Refactor? – Improve software design – Make software easier to understand – Help find bugs – Help program faster Preconditions – Working code – Good set of unit tests

When? When to refactor – Before adding functionality – Before fixing a bug – During code review When not to refactor – During adding functionality – During fixing a bug – No good set of unit tests – Small programs (usually)

Code Smells “If it stinks, change it” – Duplicate code – Switch statements – Long method – Data class – Long parameter list – Primitive obsession – Temporary field – …

Documented Refactorings There’s a catalog – Fowler’s book – There are many others Way to learn good OOD principles Pay attention to the mechanics There are automatic tools as well – Java Refactoring Browser, refactorit.comrefactorit.com

Encapsulate Field Before: public String name; After: private String name; public String getName() { return name; } public void setName(String n) { name = n; }

Introduce Null Object Before: if (project == null) plan = Plan.default(); else plan = project.getPlan(); After: class NullProject implements Project { public Plan getPlan() { return Plan.default(); } // other Project methods }

Parameterize Method Before: class Server { handleGet( … ) handlePut( … ) handleSet( … ) } After: class Server { handle(EventType et, … ) }

Extract Subclass

Extract Interface

Pull Up Method

Replace Type Code with State/Strategy

Replace Inheritance with Delegation

Hide Delegate Obeys the Law of Demeter

Separate Query from Modifier Obeys Command-Query Separation Database getNextResultAndAdvanceIndex Database getNextResult AdvanceIndex

Introduce Local Extension Alternative: Introduce Foreign Method

The opposites are there too Inline method (extract method) Replace Parameter with Explicit Methods (Parameterize Method) Collapse Hierarchy (Extract subclass) Remove middle man (Hide delegate) Push down method (pull up method) Replace delegation with inheritance

How to Refactor Recognize the smells Refactor in small discrete steps Test after each step Refactor in pairs Use documented refactorings Don’t mix with adding functionality or fixing a bug

Review: OOD Principles Open-Closed Principle Liskov Substitution Principle Single Choice Principle Law of Demeter Command-Query Separation Interface Segregation Principle, a.k.a. Single Responsibility Principle Dependency Inversion Principle