Extreme Programming Theory & XPeriences
description
Transcript of Extreme Programming Theory & XPeriences
![Page 1: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/1.jpg)
Extreme ProgrammingTheory & XPeriences
Arie van Deursen31 October 2000
http://www.cwi.nl/~arie/
![Page 2: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/2.jpg)
2
Software Development Risks Schedule slips Project canceled System goes sour / high defect rate Business misunderstood / changes False feature rich Staff turnover
What are your most pressingdevelopment problems?
![Page 3: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/3.jpg)
3
XP Project Characteristics Use of object technology
(use of modern language) Development team size:
2 to 20 people Developers take responsibility Participating customer
![Page 4: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/4.jpg)
4
XP Practices The Planning Game Small Releases Metaphor Simple design Testing Refactoring
Pair programming Collective ownership Continuous
integration 40-hour week On-site customer Coding standards
all appliedto the extreme
![Page 5: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/5.jpg)
5
Self-Testing Code Every class also has a TestClass TestClass methods:
set up fixture invoke code to be tested Automatically check results tear down fixture
Collect test in suites; run them all.
All tests mustrun at 100%at all times
![Page 6: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/6.jpg)
6
JUnit
http://www.junit.org
![Page 7: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/7.jpg)
7
Test First Run all tests and get green bar; Write (failing) test before coding:
if interface is unclear if implementation might be hard for every special case (if-then-else) before dealing with bug report
Modify the code to turn red into green bar
![Page 8: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/8.jpg)
8
Our Testing XPeriences Test / production code ratio of 1:2 Writing tests forced us to write
smaller methods Test case = documentation Having many test cases helps to dare
change other people’s code. Systematic reuse of each other’s tests
![Page 9: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/9.jpg)
9
Refactoring Refactoring A change made
to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior
Refactor: apply series of refactorings
InteractiveTransformation
Introduce design patterns
![Page 10: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/10.jpg)
10
Bad Smells in Code Duplicated Code Long Method Large Class Long Parameter
List Divergent Change Shotgun Surgery
Feature Envy Speculative
Generality Inappropriate
Intimacy Comments Switch Statements Data Clumps Data Class
out of the cave into the centrally heated world of objects
Delving intoeach other’sprivate parts
Need to take someresponsibility
Say it once!
And only once!
![Page 11: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/11.jpg)
11
Why Refactor? Improves the Design of Software Makes software easier to understand
Refactor first to understand unfamiliar code Small refactoring -> larger ones “Wiping the dirt off a window, so you can
see beyond” Helps you find bugs Helps you program faster
![Page 12: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/12.jpg)
12
When should you Refactor? Three strikes and you refactor
First time: just do it. Second time something similar: duplicate Third time something similar: refactor.
Add feature Fix bug Review Code
![Page 13: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/13.jpg)
13
Refactoring Process Modifying code involves:
Test (add if necessary) Refactor to increase understanding Test Add tests for change, modify until it passes; Test Refactor to bring code to simplest state Test
![Page 14: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/14.jpg)
14
Refactoring Catalog Name Summary Motivation Mechanism Examples Simple renamings
up to majorchanges to class
structure
![Page 15: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/15.jpg)
15
Refactoring XPeriences
Software improvement is explicit part of programming activity
Possible thanks to test suites Small refactorings on a daily basis Large refactorings applied
incrementally.
![Page 16: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/16.jpg)
16
Simplicity XP: Have the simplest design that runs
the current test suite: Code + tests communicate everything you
want to communicate The system contains no duplicate code The system has the fewest possible classes The system has the fewest possible methods
Achieved by constant refactoring!
![Page 17: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/17.jpg)
17
Design Through Refactoring Each change includes refactoring Each refactoring improves/repairs the
design Large refactorings done by need Each refactoring = mini design-phase
=> Death of the big design (phase) => No separation programmer/architect
![Page 18: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/18.jpg)
18
Design for Tomorrow Guess at the future. Tomorrow may never happen Learn a better way to implement a
change before the time you need it Pay cost of carrying along a more
complicated design Costs of unused generalizations >
benefits of used generalizations
![Page 19: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/19.jpg)
19
Design for Today Trust your ability to change
Rely on tests Implement changes together Use modern programming technology Remove any flexibility that isn’t useful
Design test by test: Repeatedly Write a test -> implies bit of design; Design & implement its code Refactor when necessary
![Page 20: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/20.jpg)
20
Our Design XPeriences Designs evolve Re-design = refactoring Small refactorings done every day Major refactorings:
Senior programmers involved Discussed with complete team Exploration first Implemented incrementally
![Page 21: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/21.jpg)
21
Pair Programming All production code is written with
two people looking at one machine, with one keyboard and one mouse.
If code review is good, we do it all the time
![Page 22: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/22.jpg)
22
Pair Programming XPeriences (Initial) resistance Changing pairs Discuss design, refactorings, tests Way to communicate system knowledge Improves quality (a lot) Coding is more fun, calmer, and less
solitary More (> 2) productive
![Page 23: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/23.jpg)
23
User Stories Collect requirements as user stories
Possible to explain, test, and estimate Prioritize stories in order of business
importance Development:
Estimate effort for stories Highlight technical risks / consequences
![Page 24: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/24.jpg)
24
Growing a System Have a running system from day 1. Integrate stories one by one Work with small iterations:
Approx. 3 weeks Split (combine) stories into tasks,
estimate Design, test, build, test Measure progress, learn to estimate
![Page 25: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/25.jpg)
25
Planning a Release Release: every 2 - 6 months
Fix date, cost and quality Determine scope: how many stories can be
done following development estimates Most important user stories first
Feedback / adjustment at every iteration New / modified stories Changed estimates
![Page 26: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/26.jpg)
26
The Planning Game
XP Planning: Dialog between possible and desirable Set of rules to govern building
respectful relationship Metaphor: Game
The Goal: Maximize value of software produced by
the team
![Page 27: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/27.jpg)
27
Planning Game (cont.) The Strategy:
Put the most valuable functionality into production as quickly as possible with minimal initial investment addressing risk first
The Pieces: Cards containing user stories
![Page 28: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/28.jpg)
28
Planning Game (cont.) The Players:
Business: decides what system must do Development: build the system
The Moves: Exploration: what could system do? Commitment:decide on this release Steer: Guide actual development,
adjust.
![Page 29: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/29.jpg)
29
Our Planning XPeriences Planning internal product development
Mimicked customer, “invented” stories Work in small iterations Always have a running system
Planning customer development Made planning process “XP-like” Didn’t force customer into XP game (yet…)
Learning to plan more systematically.
![Page 30: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/30.jpg)
30
XP Values Communication
Adopt practices that encourage talking & listening Simplicity
What is the simplest thing that could possibly work? Feedback
The system tests will tell you; Listen to the code! Courage
Go at top speed
![Page 31: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/31.jpg)
31
XP Basic Principles Rapid feedback Assume
simplicity Incremental
change Embracing
change Quality work
Teach learning Small initial investment Play to win Concrete experiments Open, honest communication Work with instincts Accepted responsibility Local adaptation Travel light Honest measurement
![Page 32: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/32.jpg)
32
XP Roles Programmer -- pairing, testing, coding,
designing, estimating -- courageous. Customer -- provide user stories + tests Tester -- implement functional tests Tracker -- log progress Coach -- teach to learn Consultant -- optional specialist Big Boss -- confident
![Page 33: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/33.jpg)
33
Adopting XP Have motivated team Learn practices one by one Deceivingly simple
tests, refactoring, pairing, planning Take sufficient time to learn
Course (spread over year), mentoring But make sure you try!
![Page 34: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/34.jpg)
34
Further Info K. Beck -- eXtreme
Programming eXplained
M. Fowler -- UML Distilled (2nd Ed.)
www.c2.com/wiki www.xprogramming.com
![Page 35: Extreme Programming Theory & XPeriences](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815d8f550346895dcba2d0/html5/thumbnails/35.jpg)
35
Summary: XP Practices The Planning Game Small Releases Metaphor Simple design Testing Refactoring
Pair programming Collective ownership Continuous
integration 40-hour week On-site customer Coding standards
all appliedto the extreme