1. Refactoring

2. Extreme Programming
A deliberate and disciplined approach to software development
Many success stories in the last six years
Stresses customer satisfaction
Emphasizes team work
Lightweight approach (few rules)
One of many agile methods
24-Feb-19
COSC6431

3. Agile method principles
Adaptive rather than predictive
Embrace change as part of the process
People-oriented rather than process-oriented
Reject the assumption that people are replaceable
A balance between no process and too much process
24-Feb-19
COSC6431

4. XP principles
Software engineered to be simple and elegant is as valuable as software that is complex and hard to understand
Automatic tests from day one (tests are written before/during/after the code)
Embrace changing requirements (customer feedback early)
24-Feb-19
COSC6431

5. When to use XP Systems with changing requirements High risk systems
Small groups of programmers
Typically 2-12
Testable systems
Managers and customer are also available
24-Feb-19
COSC6431

6. XP rules and practices
Central idea of agile methods is “few rules and practices”
XP has a handful of rules for four different stages of software development
Planning
Designing
Coding
Testing
24-Feb-19
COSC6431

7. Planning User stories are written
Release planning creates the schedule
Make frequent small releases
The Project Velocity is measured
The project is divided into iterations
Iteration planning starts each iteration
Move people around
A stand-up meeting starts each day
Fix XP when it breaks
24-Feb-19
COSC6431

8. Designing Simplicity Choose a system metaphor
Use CRC cards for design sessions
Create spike solutions to reduce risk
No functionality is added early
Refactor whenever and wherever possible
24-Feb-19
COSC6431

9. Coding The customer is always available
Code must be written to agreed standards
Code the unit test first
All production code is pair programmed
Only one pair integrates code at a time
Integrate often
Use collective code ownership
Leave optimization till last
No overtime
24-Feb-19
COSC6431

10. Testing All code must have unit tests
All code must pass all unit tests before it can be released
When a bug is found tests are created
Acceptance tests are run often and the score is published
24-Feb-19
COSC6431

11. Collective Code Ownership
24-Feb-19
COSC6431

12. Refactoring
Noun: “A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour”
Verb: “To restructure software by applying a series of refactorings without changing its observable behaviour
24-Feb-19
COSC6431

13. When to refactor All the time!
Indications that it’s time to refactor are known as code smells…
24-Feb-19
COSC6431

14. Code smells Duplicated code Long method Large class
Long parameter list
Divergent change
Shotgun surgery
Feature envy
Data clumps
Primitive obsession
Switch statements
Parallel Inheritance Hierarchies
Lazy class
Speculative generality
Temporary field
Message chains
24-Feb-19
COSC6431

15. More code smells Middle man Inappropriate intimacy
Alternative classes with different interfaces
Incomplete library class
Data class
Refused bequest
Comments
24-Feb-19
COSC6431

16. Refactoring catalog Many different refactorings possible
Martin Fowler lists about 80 of them in his book on Refactoring
Other refactorings have been identified as well
We’ll take a look at a few examples…
24-Feb-19
COSC6431

17. The first step: Testing
In order to refactor, you need a solid suite of tests
Tests must be automatic and self-checking
Run tests often, after every small change
The Junit framework can help with the automation part (for Java code)
24-Feb-19
COSC6431