CS 683 Emerging Technologies: Embracing Change
Spring Semester, 2001
Extreme Programming Overview
Lecture Notes Index
© 2001, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 08-Mar-01
Contents of Doc 13, Extreme Programming Overview
New Methodology, Martin Fowler,
Improving the Design of Existing Code, Martin Fowler, 1999
Programming Explained: Embrace Change, Beck, 2000
is a lightweight way to produce software
March 6, 1996 with
to write a payroll system for Chrysler
done in Smalltalk
Beck brought in to help an existing project
System Development Method
methods are adaptive rather than predictive
methods are people-oriented rather than process-oriented.
the wrong product
for product changes
many features that users don't want
between management and developers
can't manage risks than it is hard to succeed
Struggle between Management & DeveloperThe Developer Bill of Rights
have the right to know what is needed, via clear requirements, with clear
declarations of priority
have the right to say how long each requirement will take you to implement, and
to revise estimates given experience
have the right to accept your responsibilities instead of having them assigned
have the right to produce quality work at all times
have the right to peace, fun, and productive and enjoyable work
Customer Bill of Rights
have the right to an overall plan, to know what can be accomplished, when and
at what cost
have the right to see progress in a running system, proven to work by passing
repeatable tests that you specify
have the right to change your mind, to substitute functionality, and to change
have the right to be informed of schedule changes, in time to choose how to
reduce scope to restore the original date. You can even cancel at any time and
be left with a useful working system reflecting investment to date
Variables of Software Development
much money to spend developing the product
little money makes it hard to develop the product
much money too soon causes problems
time allocated to develop the product
little time makes development impossible
much time hurts development
feedback from system in use
least measurable variable
first to suffer in a crunch
quality increases development time and costs
features will be in the product
and Development Time
between Four Variables
interaction between is non-linear
a program takes one programmer a year to develop
we use 50 programmers to develop it in a week or
250 programmers to develop it in a day?
Planning Game - Greatly Simplified
writes user stories for the product
story is a short description of the behavior of the product
ranks stories by importance
estimate development time per story
customer ranks & developers estimates the stories for next iteration are
story into small tasks
the task they wish to work on
implement a task
tests for the task
the code for the task
to clean up design
task into code base
is the design of existing code with adding more functionality
does that mean?
Example - Problem 3
at: anInteger put: anObject
(smallKey ~= largeKey)
[(anInteger < smallKey)
ifTrue: [self atLeftTree: anInteger put: anObject]
ifFalse: [(smallKey = anInteger)
ifTrue: [smallValue := anObject]
ifFalse: [(anInteger < largeKey)
ifTrue: [self atMiddleTree: anInteger put: anObject]
ifFalse: [(largeKey = anInteger)
ifTrue: [largeValue := anObject]
ifFalse: [(largeKey < anInteger)
ifTrue: [self atRightTree: anInteger put: anObject]]]]]]
[self addNewKey: anInteger with: anObject].
"Replace Nested Conditional with Guard Clauses"
refactoring to get:
at: anInteger put: anObject
smallKey ~= largeKey
ifFalse: [^self addNewKey: anInteger with: anObject].
anInteger < smallKey
ifTrue: [^self atLeftTree: anInteger put: anObject].
smallKey = anInteger ifTrue: [^smallValue := anObject]
anInteger < largeKey
ifTrue: [^self atMiddleTree: anInteger put: anObject]
largeKey = anInteger ifTrue: [^largeValue := anObject]
largeKey < anInteger
ifTrue: [^self atRightTree: anInteger put: anObject]
get the code below I applied:
Conditional with Polymorphism
^root at: aKey
aKey < smallData key ifTrue:[^leftSubtree at: aKey].
aKey = smallData key ifTrue:[^smallData value].
aKey < largeData key ifTrue:[^middleSubtree at: aKey].
aKey = largeData key ifTrue:[^largeData value].
aKey > largeData key ifTrue:[^rightSubtree at: aKey]
aKey = data key
ifFalse:[self error: 'Key not found']
self error: 'Key not found'
Copyright ©, All rights reserved.
2001 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.
visitors since 08-Mar-01