Post on 28-Oct-2014
description
1
eXtreme Programmingמתודולוגיה לפיתוח פרויקטי תוכנה
ד"ר אורית חזן
המחלקה להוראת הטכנולוגיה והמדעים
הטכניון
2
eXtreme Programming מתודולוגיה לפיתוח פרוייקטי תוכנה
Round 1:
What is eXtreme Programming
Why eXtreme Programming?
How eXtreme Programming? Actual implementation
Round 2:
What is eXtreme Programming? Further details
Why eXtreme Programming? Further analysis
How eXtreme Programming? Further elaboration
3
eXtreme Programming מתודולוגיה לפיתוח פרוייקטי תוכנה
על-סמך ניסיונכם עד היום בפיתוח
תוכנה:
מהן הבעיות המרכזיות המאפיינות
פרויקטי תוכנה?
4
Google: "problems with software development”
Requirements are complex
Clients usually do not know all the requirements in advance
Requirements may be changing
Frequent changes are difficult to manage
Process bureaucracy (documents over development)
It takes longer
The result is not right the first time
It costs more
Applying the wrong process for the product
Problems in software development
5
בעיות מאפיינות של פרוייקטי תוכנה
הסיבוכיות האמיתית בפיתוח תוכנה
)ולא הטכנולוגי(מקורה בהיבט האנושי
,לקוחות, לו"ז לחוץ ואי-עמידה בו, באגים
הבנה של תוכניות, תקשורת בין חברי צוות,
אי-שיתוף מידע, אינטגרציה, ...
6
פרויקטי תוכנה: נתונים
75%נחשבים הגדולים הנשלחים ללקוחות ממוצרי התוכנה
: או שאינם בשימוש כלל או שאינם מתאימים ככישלון
.לדרישות הלקוחות Based on: Mullet, D. (July, 1999). The Software Crisis, Benchmarks Online - a monthly
publication of Academic Computing Services 2(7).
בתוכנה בארה"ב נאמדת בכל שנה תיקונם של באגים עלות
ביליון 59.5$ב- The National Institute of Standards and Technology (NIST), New Release of June 28, 2002.
:ב- לשם השוואהQ2 ביליון 200$בתוכנה הושקעו בארה"ב 2003 של
7
What is eXtreme Programming
מה אתם יודעים עלXP?
8
What is eXtreme Programming
eXtreme Programming .צמחה בתעשייה
Differences from traditional methodologies Emphasis on people vs. development activities & schedule
XP specifies how to behave; still leaves freedom
12 practices
4 values: feedback, simplicity, communication, courage
The meaning of ‘eXtreme’
Optimum: teams up to 12 developers; can be adjusted
to bigger teams.
9
Why XP ? Survey:
31 XP/Agile-methods early adopter projects
14 firms
Findings:
Cost reduction: 5-7% on average
Time to market compression: 25-50% reduction
This datum will be explained later
10
Why XP ?
big companies using XP in at least some capacity
Ford Motor, Chrysler, IBM, HP
smaller software houses:
Mayford Technologies
RoleModel Software
tutorials: Industrial Logic, Object Mentor
11
How eXtreme Programming?
Two days in
eXtreme Programming
Development Environment
12
How eXtreme Programming?
Business Day
יישום מיומנויותXP הקשורות להגדרת דרישות
התוכנה ותכנון תהליך הפיתוח
בחירת נושא
התנסות במיומנויות
13
Business Day
On-site customer
Planning game
Small releases
Simple design
Metaphor
Source: http://www.rolemodelsoftware.com/
14
Business Day – Reflection
5 practices (out of 12)
Planning gameOn-site customerSmall releasesSimple designMetaphor
Planning game
All developers participate
All have the same load
All developers get an overview of the entire development process
Simple means
Very detailed
Levels of abstraction
15
Business Day – Reflection
5 practices (out of 12)
Planning gameOn-site customerSmall releasesSimple designMetaphor
On-site customer
Customer’s on-going
feedback
Small releases
On-going opportunity to
update/change
requirements
16
Business Day – Reflection
5 practices (out of 12)
Planning gameOn-site customerSmall releasesSimple designMetaphor
Simple design
Develop only what is
needed for your
development task
Metaphor Bridges customers-
developers-business gaps
17
הפסקה
18
Development Day
Stand-up meeting The development environment
Pair programming Test driven development (acceptance, unit-test) Code standards Refactoring Simple design Continuous integration (one integration machine) Collective ownership Sustainable pace (40-hour week)
Source: http://www.rolemodelsoftware.com/
19
Development Day - Reflection
The development environment All see all; fosters communication
Stand-up meeting All know what all do
Pair programming Each task is thought on two levels of abstraction
Unit test (automatic test first) First: improves understanding; Automatic: testing is easy
Developers program and test
Testing becomes manageable
Success vs. failure
20
Development Day - Reflection
Continuous integration
Reduces integration risks in later stages
Collective ownership Important in companies with high turnover
Coding standards
Refactoring and simple design Code improvement is part of the methodology (though it doesn't
produce code), gradual process
Sustainable pace (40-hour week) Intense and productive work, developers are not tired
21
Development and Business Days – Reflection
Code/Technical Perspective
Human/Social Perspective
Refactoring
Simple design
Coding standards
Testing
Continuous integration
Small releases
Collective ownership
Pair programming
Sustainable pace
On-site customer
Planning game
Metaphor
22
The 12 XP practices
Note:nothing is new; gathering the practices together is XP uniqueness
Source: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.
23
eXtreme Programming מתודולוגיה לפיתוח פרוייקטי תוכנה
Round 1:
What is eXtreme Programming
Why eXtreme Programming?
How eXtreme Programming?
Round 2:
What is eXtreme Programming? Further details
Why eXtreme Programming? Further analysis
How eXtreme Programming? Further elaboration
24
What is eXtreme Programming
Differences from traditional methodologies
All developers are involved with requirements-design-code-testing
Emphasis on people vs. development activities & schedule
XP specifies how to behave; still leaves freedom and place for creativity
The meaning of ‘eXtreme’
12 practices
4 values: feedback, simplicity, communication, courage
25
What is eXtreme Programming
Agile Software Development Methodology
Other agile methods: SCRUM, Feature Driven
Development, DSDM
All acknowledge that the main issue of software
development is people: customers, communication
Manifesto for Agile Software Development: http://
agilemanifesto.org/
eXtreme Programming: Kent Beck, 1996, Chrysler
26
Why XP ?
You do not do XP to save money;
However, XP shortens time to market
XP is a mature software development
method
27
Why XP ?
Survey:
31 XP/Agile-methods early adopter projects, 14 firms
Findings:
Cost reduction: 5-7% on average
Time to market compression: 25-50% reduction in
time
28
Why XP? – Analysis Shorter development period:
Code is easy-to-work with:
less bugs: unit tests
code is more readable & workable (invest now to gain benefits
later):pair programming, refactoring, coding standards
Development is manageable and controlled:
accurate estimation: small releases
meets customer needs: customer on-site, planning game, acceptance
tests
29
Why XP? – Analysis Shorter development period )cont(:
Knowledge sharing, if one leaves everything continues
as usual: pair programming, collective ownership
Production is increased: pair programming (work all the time),
sustainable pace
Cost for requirements change/update/elaboration is
CONSTANT: simple design, planning game (redundant features
are not added by customer and developers)
30
Why XP ?Barry W. Boehm (1981). Software Engineering Economics,
Englewood Cliffs, N.J.: Prentice Hall.
63 software development projects in corporations such as IBM.
Phase of requirement change Cost Ratio
Requirements 1
Design 3-6
Coding 10
Development testing 15-40
Acceptance testing 30-70
Operation 40-1000
31
Why XP ? Under the assumption that “the later a requirements is
introduced the more expensive it is”, customers (and
developers) try to make a “complete” list of requirements.
Under the assumption that “cost for introducing an update in
the requirements is constant”, customers (and developers) do
not assume what the customer will need and develop exactly
and only what is needed.
32
Why XP ?
You do not use XP to save money;
However, XP shortens time to market
XP is a mature software development
method (at least CMM level 3)
33
XP in Practice: Conceptual Changes
XP encourages:
Cooperation (vs. knowledge-is-power)
Simplicity (vs. habit-of-high-complexity)
Change in work habits
34
Why XP? – Cognitive and Social Analysis
הסבר הצלחתXP מנקודת מבט קוגניטיבית
וחברתית.
Prisoner’s Dilemma Analysis of XP within the framework of the Prisoner’s
dilemma
Constructivism Analysis of XP within the framework of constructivism
GAPS (abstraction, satisfaction)
35
Social analysis
36
Game Theory
ניתוח התנהגות וקבלת החלטותכאשר תוצאות הנובעות מהחלטות
של כל אחד מהמשתתפים ב"משחק" תלויות בהחלטות של המשתתפים
האחרים.
37
The Prisoner’s Dilemma: A’s perspective
B cooperatesB competes
A cooperates+5-10
A competes+100
38
The Prisoner’s Dilemma: The case of software engineering – A’s perspective, Bonus
B cooperatesB competes
A cooperates50%20%
A competes80%0%
39
The Prisoner’s Dilemma: The case of software engineering – A’s perspective
B cooperatesB competes
A cooperates+5-10
A competes+10-20
40
The Prisoner’s Dilemma: The case of software engineering
בד"כ מפתחי תוכנה מתבקשים לשתף פעולה עם
עמיתיהם.
למפתחי התוכנה אין אפשרות לוודא ששיתוף הפעולה
שלהם יהיה הדדי.
:כל חברי הצוות יעדיפו לבגוד (לא לפי דילמת האסיר
לשתף פעולה).
התנהגות כזו בפיתוח תוכנה מביאה לתוצאות הגרועות
ביותר לכל חברי הצוות.
41
The Prisoner’s Dilemma: The case of eXtreme Programming
לעבוד על-פי התחייבות חברי הצוותXP מבטיחה שכל
. XPחברי הצוות יעבדו על-פי המיומנויות של
כל חבר(ת) צוות יודע(ת) שגם שאר חברי הצוות
מחויבים לעבוד לפי אותן מיומנויות.
(המהווה את המקור לדילמת האסיר) גורם האי-וודאות
לא קיים.
.כולם ישתפו פעולה ויפיקו את הרווחים מכך
42
The Prisoner’s Dilemma: The case of Extreme Programming – A’s perspective
B cooperates
A cooperates+5
43
In what follows-מיומנויות של 4 ערכים ו- 2ביחס ל XP:
.מהי המשמעות של שיתוף פעולה הנובעת מהם
מהעובדה שכל הצוות מחויב לעבוד על-פי XP נובע שכל
אחד ואחת מחברי הצוות אינם ניצבים בפני הדילמה האם
.(באותו מובן הנובע מהערך או המיומנות) לשתף פעולה
כל חברי הצוות משתפים פעולה ומרוויחים מהיתרון שנובע
. מאותו ערך או מיומנות
.כל פרויקט התוכנה נתרם משיתוף פעולה זה
44
The Prisoner’s Dilemma: The value of courage
:שיתוף פעולה
.כל חברי הצוות מתריעים כאשר יש בעיה
.כל חברי הצוות אינם מתביישים להודות כאשר חסר להם ידע
.כל חברי הצוות אינם חוששים לשנות קוד של עמיתיהם
מכיוון שסביבת הפיתוח היאXP כל אחד(ת) יודע(ת) שהם לא ,
ולכן הם לא עומדים בפני הדילמה האם courageהיחידים שיפגינו
לשתף פעולה.
.הפרויקט וחברי הצוות מרוויחים מערך זה
45
The Prisoner’s Dilemma: The value of simplicity
:שיתוף פעולה יישום כל הפעולות הקשורות בפיתוח התוכנה בצורה
הפשוטה ביותר.
.למשל, לא מסבכים קוד
כולם מחויבים לעבוד על-פיXP ולכן מחויבים גם לערך הזה.
.לא ניצבים בפני הדילמה האם לשתף פעולה
.כולם משתפים פעולה וכולם מרוויחים
46
The Prisoner’s Dilemma: Collective Ownership
In practice “[a]nyone can change any code
anywhere in the system at any time.” (Beck, 2000).
:הסתרת קוד. בגידה:שיתוף בקוד. שיתוף פעולה
כולם עובדים על-פי XP.ולכן גם על-פי מיומנות זו
.לא עומדים בפני הדילמה האם לשתף פעולה
כולם משתפים פעולה, הדבר תורם לתהליכי פיתוח
התוכנה וכולם יוצאים נשכרים.
47
The Prisoner’s Dilemma: Coding Standards
:פיתוח לפי הסטנדרטים שנקבעו. שיתוף פעולה
:פיתוח לא על-פי הסטנדרטים שנקבעו.בגידה
כל חברי הצוות מחויבים לעבוד על-פיXP בכלל
ועל-פי מיומנות זו בפרט.
.חברי הצוות אינם מתלבטים האם לשתף פעולה
כל חברי הצוות משתפים פעולה ומרוויחים
מהיתרונות שבפיתוח קוד על פי סטנדרטים.
48
The Prisoner’s Dilemma: Simple Design
נובע מהערךSimplicity
:פיתוח בגידה: פיתוח פשוט ככל האפשר; שיתוף פעולה
מסובך היכול להקשות על הבנה.
כולם מחויבים לעבוד על-פיXP.ולכן גם על-פי מיומנות זו
.חברי הצוות אינם מתלבטים האם לשתף פעולה
כולם משתפים פעולה ומרוויחים מהיתרונות שבפיתוח
קוד פשוט ככל שניתן.
49
The Prisoner’s Dilemma: Sustainable Pace
שעות, למעט מקרים חריגים.40שבוע עבדה בן
:מפתחים עייפים אינם מייצרים קוד איכותי. רציונאל
מיומנויות אחרות)e.g., Pair Programming( .מבטיחות ניצול יעיל של זמן זה
:עבודה במשך שעות בגידה: ביום; 8-9עובדים שיתוף פעולה
. (למשל, על מנת להרשים)רבות יותר
כל חברי הצוות מחויבים לעבוד לפיXP.ולכן גם לפי מיומנות זו
.חברי הצוות אינם מתלבטים האם לשתף פעולה
כולם משתפים פעולה ומרוויחים מהיתרונות שבפיתוח קוד
בקצב שניתן לעמוד בו.
50
Cognitive analysis
51
Why XP?
:הבנת סביבת פיתוח תוכנה היא תהליך טענה
תומכת בתהליך הבנה זה. XPמורכב;
:קונסטרקטיביזם.תיאוריה המסבירה תהליכי למידה
ידע חדש נבנה בהדרגה על בסיס מושגים קיימים, ע"י ארגון
ועידון מבנים מנטאליים קיימים.
למשוב שמתקבל מסביבת הלמידה תפקיד חשוב בתהליך
הלמידה.
52
XPניתוח קוגניטיבי של
המיומנויות של 12 מתוך 4בחינת XP משקפיים דרך
. קונסטרוקטיביסטיות
בהבנה הדרגתית של סביבת מיומנויות אלו תומכים
.הפיתוח
הערכים Communication -ו Feedback .אף הם תורמים
53
XP practices - Cognitive analysis
• Small releasesGradual process of knowledge construction re requirements
• RefactoringGradual process of knowledge construction re code's structure and
readability
• Test driven development
• Metaphor
54
Cognitive and Social Analysis of XP practices
Cognitive analysisSocial analysis
Refactoring
Metaphor
Test-first
Small releases
Collective ownership
Sustainable pace
Simple design
Coding standards
55
Bridging Cognitive and Social Gaps
in Software Development using
Extreme Programming
Based on:
Hazzan, O. and Dubinsky, Y. (2003). Bridging cognitive and social chasms in software
development using Extreme Programming, Proceedings of the Fourth International
Conference on eXtreme Programming and Agile Processes in Software Engineering,
Genova, Italy, pp. 47-53.
56
מה משותף לאמירות הבאות?
אני חייבת לקבל תמונה כללית של המערכת כדי"
לדעת האם המתודה הזאת רלוונטית בכלל. "
אני באמת חושב שאם הייתי יכול לחשוב על שתי"
המחלקות האלה באופן יותר מופשט, הייתי מגיע
למסקנה שניתן לייצגן ע"י מחלקה אחת. אבל אני
חייב לעבור למשימת הפיתוח הבאה שלי".
57
מה משותף לאמירות הבאות?
אני צריכה קצת זמן לחשוב על הקוד מבלי
להיות מוצפת בכל הפרטים. אני כמעט בטוחה
שאם הייתי יכולה לעזוב עכשיו וללכת לשחות,
הייתי יכולה למצוא פתרון. אבל. מה לעשות, אני
חייבת להישאר מאוחר כמו כל הצוות שלי". הלוואי והייתי יכול להצטרף למתכנת כאשר"
הוא יכתוב את הקוד. למה? אני לא בטוח אם
".C הזה ב- designניתן לממש את ה-
58
מה משותף לאמירות הבאות?
אני חייבת לקבל תמונה כללית של המערכת כדי"
לדעת האם המתודה הזאת רלוונטית בכלל. "
אני באמת חושב שאם הייתי יכול לחשוב על שתי"
המחלקות האלה באופן יותר מופשט, היית מגיע
למסקנה שניתן לייצגן ע"י מחלקה אחת. אבל אני
חייב לעבור למשימת הפיתוח הבאה שלי".
59
מה משותף לאמירות הבאות?
אני צריכה קצת זמן לחשוב על הקוד מבלי
להיות מוצפת בכל הפרטים. אני כמעט בטוחה
שאם הייתי יכולה לעזוב עכשיו וללכת לשחות,
הייתי מוצאת איזה פתרון. אבל מה לעשות, אני
חייבת להישאר מאוחר כמו כל הצוות שלי". הלוואי והייתי יכול להצטרף למתכנת שיכתוב"
את הקוד. למה? אני לא בטוח אם ניתן לממש
.C הזה ב- designאת ה-
60
מה משותף לאמירות הבאות?
של ... תמונה כלליתאני חייבת לקבל •
לחשוב על שתי אני באמת חושב שאם הייתי יכול•
... המחלקות האלה באופן יותר מופשט
מבלי להיות אני צריכה קצת זמן לחשוב על הקוד •
. ... מוצפת בכל הפרטים
הזה ב- designניתן לממש את ה- אני לא בטוח אם•
C.Abstraction
Level
61
Abstraction levelsingle multiple
A Cognitive Gap: Abstraction
XP מנחה חשיבה ברמות הפשטה שונות ואת המעבר ביניהן.
62
abstraction gap: single vs. multiple abstraction level
Planning Game
the release planning game is carried out on a high level of
abstraction; in the release planning a global view is gained
the iteration planning game is carried out on a lower level of
abstraction; details are added only with respect to the
forthcoming iteration
the entire team participates in the planning game; developers
see the entire picture of the system (and its parts)
63
abstraction gap )cont(: single vs. multiple abstraction level
Small Releases
guide not to stay for too long a time in too high level of
abstraction or too low level of abstraction
Pair Programming
the two individuals in the pair think at different levels of
abstraction; the same development task is thought about at
two different levels of abstraction
64
abstraction gap )cont(: single vs. multiple abstraction level
Sustainable Pace
enables detachment from the details involved in software
development and thinking on higher levels of abstraction
Refactoring and Simple Design
in order to improve a piece of code one has to examine it from
a higher level of abstraction
examining low level of abstraction (the code) from higher level
of abstraction (the design that guides the simplicity)
65
Satisfaction
needs, points of view
individual collective
A Social Gap: Satisfaction
XP מנחה לא להסתפק בסיפוק הצרכים של הפרטים
בצוות אלא לשקול גם את צרכי שאר חברי הצוות.
66
satisfaction gap: individual vs. collective satisfaction
On-site Customer
enables developers to refrain from making decisions with
respect to customer’s needs without first checking with the
customer as to what is really needed
67
satisfaction gap )cont(: individual vs. collective satisfaction
Pair Programming
crossing the gap between individual’s tendency to skip tests,
check email, browse the web, etc. and the the benefits that
the collective gains from pair programming
Coding Standards
reduces programmers’ tendency to write code in a way that is
understood only to them
68
satisfaction gap )cont(: individual vs. collective satisfaction
Collective Ownership
one knows that everyone looks at what one programs and
improves it if it is not good enough
one postpones immediate satisfaction to move on and
improves one’s code prior to its integration
Sustainable Pace
one can dedicate more time to one’s personal life without
having to satisfy the expectations of co-workers to put in long
hours of overtime
69
satisfaction gap )cont(: individual vs. collective satisfaction
Refactoring
it is not sufficient that the code passes all tests, it should also
be refactored, restructured and improved
one should postpone his or her immediate needs and invest
more effort in refactoring before moving on
Simple design
it is not sufficient that the code passes all the tests, its design
should also be simplified as much as possible before one
moves on to the next development task
70
Gaps: Summary
A cognitive gap: abstraction
A social gaps: satisfaction
Suggestions for additional gaps?
71
How eXtreme Programming?
Refactoring
72
Refactoring in Extreme Programming
73
Agenda Introductory questions
Example
Refactoring: Focus on its nature, not on techniques What is refactoring?
Why refactoring?
How refactoring?
Why refactoring hard?
XP and refactoring
Summary
74
Introductory Questions
מתי אתם לא מרוצים מקוד שכתבתם? מה אתם
עושים במצבים כאלה?
ראש הצוות שלכם מבקשת מכם לכתוב את הקוד
כל שהוא יהיה קריא יותר. כיצד תגיבו?
חבר לצוות מספר שמה שחשוב לו בפיתוח תוכנה
הוא שהקוד רץ. לכן, ברגע שהקוד שכתב עובר את
כל הבדיקות, הוא עוזב את הקוד ולא משפר את
המבנה והעיצוב שלו. כיצד תגיבו?
75
Example
A given design
Source: Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, don Roberts. (2002). Refactoring: Improving the Design of Existing Code, Addison-Wesley.
76
Example
A given design:
Is it well designed?
In what cases may it
cause problems?
Would you change it?
If yes: suggest alternative designs.
77
Example – Reflection
How it emerged? Deal was originally being used to display a single deal. Someone wanted a table of deals. The subclass Tabular Active Deal displays a table. Now you want tables of passive deals. Another subclass is added. Small changes in many places. The code has become complicated, time is pressing, ... Adding a new kind of deal is hard, because the deal logic is
tangled with the presentation logic.
78
Example – Reflection
How it emerges? – In general
“One day you are adding one little subclass to do a little
job. The next day you are adding other subclasses to do
the same job in other parts of the hierarchy. A week (or
month or year) later you are swimming in spaghetti.
Without a paddle.” (Fowler)
79
Example – Reflection
Problems in tangled inheritance:
It leads to code duplication.
It makes changes more difficult:
Strategies for solving a certain problem are spread around.
The resulting code is hard to understand.
80
Example – Reflection
How tangled inheritance can be observed? Spot for a single inheritance hierarchy that is doing 2 jobs.
“If every class at a certain level in the hierarchy has subclasses
that begin with the same adjective, you probably are doing two
jobs with one hierarchy.”
Why it can not be coded “correctly” at the first
stage?
Step-by-step refactoring (Fowler’s style)
81
Example – Step by Step Refactoring
First step: identify the jobs being done by the
hierarchy.
Job #1: capturing variation according to type of deal.
Job #2: capturing variation according to presentation
style.
82
Second step: decide which job is more
important.
The dealness of the object is far more
important than the presentation style.
Leave Deal alone and extract the
presentation style to its own hierarchy.
Example – Step by Step Refactoring
83
Example – Step by Step Refactoring
Third step: use Extract Class to create a
presentation style.
Extract Class You have one class doing work that should be done by
two.
Create a new class and move the relevant fields and
methods from the old class into the new class.
84
Example – Step by Step Refactoring
Fourth step: Create subclasses of the extracted
class and initialize the instance variable to the
appropriate subclass.
Adding subclasses of presentation style
85
Example – Step by Step Refactoring
Fifth step: Use Move Method and Move Field to
move the presentation-related methods and
variables of the deal subclasses to the
presentation style subclasses.
No code left in the classes Tabular Active Deal and Tabular Passive Deal. Remove them.
86
Example – Step by Step Refactoring
Sixth step: Separate the hierarchies: Distinguish
between single and tabular.
87
Example Original Refactored
88
Example - Reflection
What did we do?
Is there a difference between the two designs? If yes – what is it?
How is this change supposed to improve our life?
In what way may the change be useful for someone who did not write the code?
How did the need for refactoring emerge?
Couldn’t we write the code refactored from the beginning?
89
Example - Summary
Tease Apart Inheritance
You have an inheritance hierarchy that is doing
two jobs at once.
Create two hierarchies and use delegation to
invoke one from the other.
This format guides Fowler’s book.
90
Example - Summary
Delegation:
The ability of an object to issue a message to another
object in response to a message. Delegation can be used
as an alternative to inheritance. Contrast: inheritance.
Source: OMG Unified Modeling Language Specification.
More about inheritance vs. delegation:
http://www-inst.eecs.berkeley.edu/~cs61a-tb/week8/oop.html
91
Refactoring
In what follows:
What is refactoring?
Why refactoring?
When refactoring? When not?
How refactoring?
Why refactoring hard?
XP and refactoring
92
Refactoring
Fowler: Refactoring is the process of changing a software
system in such a way that it does not alter the external
(observable) behavior of the code yet improves its
internal structure, to make it easier to understand and
cheaper to modify.
Kent (in Fowler, p. 51): Refactoring is the process of
taking a running program and adding to its value, not by
changing its behavior but by giving it more of these
qualities that enable us to continue developing at speed.
93
Refactoring
What do programmers do when refactoring:
remove duplication
improve communication and program
comprehension
add simplicity
add flexibility
94
Refactoring – Metaphors
Three metaphors for refactoring :
relationships with your program
parenthesis
health
95
Refactoring – Metaphors I
[Refactoring] is like a new kind of relationship with your
program. When you really understand refactoring, the
design of the system is as fluid and plastic and moldable
to you as the individual characters in a source code file.
You can feel the whole design at once. You can see how
it might flex and change – a little this way and this is
possible, a little that way and that is possible. (Kent, in
Fowler, p. 333)
96
Refactoring – Metaphors II
Parenthesis )by Alistair Cockburn(:
“I started seeing 5*a + b*a as 3 operations on 6 things.
(5+b)*a is 2 operations on 3 things.
You can see the jump to OO programming.
Let's take the case of
A.method1() = ... b.doThis(); b.doThat(); ...
I change the code to
B.doThisThat() = doThis(); doThat().
A.method1() = ... b.doThisThat(); ...
97
Refactoring – Metaphors II
Alistair Cockburn (cont.): […] That change corresponds
(in my mind, anyway) exactly to the (5+b)*a refactoring.
Nowadays, I see a method and a class as a set of
parentheses, and when I move code out of one method
or class to another, I visualize it just as moving symbols
from one set of parentheses to another. Of course, the
net effect of the computation has to be the same, […] it
has to be a behavior preserving transformation.”
98
Refactoring – Metaphors III
Refactoring as health: exercises and eating a proper diet.
The culture we live in.
We can always make excuses, but we are only fooling
ourselves if we continue to ignore good behavior.
Near-term and long-term benefits.
99
Refactoring
Main questions:
What is refactoring? OK
Why refactoring?
When refactoring? When not?
How refactoring?
Why refactoring hard? Why people do not do that?
XP and refactoring
100
Why Refactoring
Refactoring improves the design of the software
fosters the examination of the software design
removes duplicated code:
reduces the amount of code
the code says everything once and only once
101
Why Refactoring
Refactoring makes software easier to understand
helps make your code more readable
increases program comprehension: leads to higher
levels of understanding that otherwise may be missed
102
Why Refactoring
Refactoring helps you program faster
sounds counterintuitive
less bugs, no patches
helps correct bugs: errors need to be modified
only in one place
103
Refactoring
Main questions:
What is refactoring OK
Why refactoring? OK
When refactoring? When not?
How refactoring?
Why refactoring hard? Why people do not do that?
XP and refactoring
104
When refactoring
You have written some code. Now, if you work
by XP, you should refactor it.
How would you find what to refactor?
What clues in the code may guide you?
Fowler, chapter 3 – Bad smells in code
105
When refactoring Fowler, Chapter 3 – Bad smells in Code
Duplicated Code:
“If you see the same code structure in more than one
place, you can be sure that your program will be better
if you find a way to unify them”.
Extract Method: When you have the same expression
in two methods of the same class.
106
When refactoring Fowler, Chapter 3 – Bad smells in Code
Long Method:
“the longer the procedure is, the more difficult it is to
understand”.
Extract method: find parts of the methods that seem
to go nicely together and make a new method.
107
When refactoring Fowler, Chapter 3 – Bad smells in Code
Comments: “if you need a comment to explain what a block of code
does, try Extract Method. If the method is already extracted
but you still need a comment to explain what it does, use
Rename Method.”
“when you feel the need to write a comment, first try to
refactor the code so that any comment becomes
superfluous”.
“a comment is a good place to say why you did something.
This kind of information helps future modifiers”.
108
When shouldn't you refactor?
When the code is a mess and it would
be better to start from the beginning.
Factors that will be discussed later:
Culture
Internal resistance
109
Refactoring
Main questions:
What is refactoring OK
Why refactoring? OK
When refactoring? When not? OK
How refactoring?
Why refactoring hard? Why people do not do that?
XP and refactoring
110
How Refactoring
Rasmusson (2002): “The team must refactor all the
time, to the fullest extent. When we didn't follow this
rule, the code became more cumbersome to work
with”.
Most of the time it is done in small and local places
Sometimes: a sequence of refactoring
Refactoring requires high level of awareness
All the time
Two hats: adding functions and refactoring
111
How refactoring Resources for specific refactoring:
Refactoring Home Page: http://www.refactoring.com
Martin Fowler, Kent Beck (Contributor), John Brant
(Contributor), William Opdyke, don Roberts (1999).
Refactoring: Improving the Design of Existing Code,
Addison-Wesley. Many of the citations in this refactoring presentation are from the
book.
Some IDEs (Integrated development environments)
offer Refactoring menu Example: Eclipse, IntelliJ
112
Refactoring
Main questions:
What is refactoring OK
Why refactoring? OK
When refactoring? When not? OK
How refactoring? OK
Why refactoring hard? Why people do not refactor?
XP and refactoring
113
Why refactoring hard ?
Sub-questions:
Why people do not refactor naturally?
Why does refactoring raise resistance?
114
Why refactoring hard ?
Culture:
“refactoring is an overhead activity. I’m paid to write
new, revenue-generating features”.
“What do I tell my manager?”
When it is part of XP – You do not have a problem
When it is not part of XP: Don’t tell!!
Treat it as part of the profession: This is how you develop
code, it is not viewed by you as an additional work.
115
Why refactoring hard ?
Internal resistance: Why are developers reluctant to
refactor? (Opdyke, in Fowler’s book, p. 313)
it should be executed when the code runs and all the
tests pass. It seems that time is wasted now.
if the benefits are long-term, why exert the effort now?
In the long term, developers might not be with the
project to reap the benefits.
developers might not understand how to refactor.
refactoring might break the existing program.
116
Refactoring
Main questions:
What is refactoring OK
Why refactoring? OK
When refactoring? When not? OK
How refactoring? OK
Why refactoring hard? OK
XP and refactoring
117
XP and Refactoring
Refactoring is part of eXtreme Programming:
Refactoring can be carried out without XP, but it has
additional value with XP
It has similar targets to those that XP inspires
When refactoring is part of XP:
refactoring becomes part of the routine
it stops feeling like an overhead activity
118
XP and Refactoring
Mutual relationships of refactoring and other XP practices
Source: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.
119
XP and Refactoring
Connection to XP practices - example
Testing: “Whenever I do refactoring, the first step is
always the same. I need to build a solid set of tests for
that section of code. The tests are essential because
even though I follow refactoring structures to avoid
most of the opportunities for introducing bugs, I'm still
human and still make mistakes.Thus I need solid
tests.” (Fowler, p. 17)
120
Refactoring
Main questions:
What is refactoring OK
Why refactoring? OK
When refactoring? When not? OK
How refactoring? OK
Why people do not refactoring? OK
XP and refactoring OK
121
Refactoring – Summary
Refactoring requires awareness!
Main Message:
We should not skip refactoring.
Software development is a process that cannot be
envisioned in advance.
Refactoring can be performed without XP but it gets its
power from its integration with the other XP practices.
Refactoring may improve programming skills.
122
Summary
eXtreme programming:
What?
Why?
How?
123
Conferences
XP 2004: Fifth International Conference on Extrem
e Programming and Agile Processes in Software E
ngineering
, June 6-10, 2004, Garmisch-Partenkirchen,
Germany
Agile Development Conference, June 23-26, 2004,
Salt Lake City, Utah.
XP Agile Universe 2004, August 2004, Calgary,
Alberta, CA.
124
ReferencesBeck, K. (2000). Extreme Programming Explained: Embrace
Change, Addison Wesley.
Ron Jeffries, What is Extreme Programming?: http://www.xprogramming.com/xpmag/whatisxp.htm
eXtreme Programming at the Technion
RoleModel:http://www.rolemodelsoftware.com/process/whatIsXp.php
125
Questions (Musical cards)
126
Appendices
XP and the CMM
XP conception of failure and success
127
Why XP? – XP is a Mature Method
The Capability Maturity Model for Software (CMM or
SW-CMM): a model for judging the maturity of the
software processes of an organization and for
identifying the key practices that are required to
increase the maturity of these processes.
The Software CMM has become a de facto standard
for assessing and improving software processes.
128
Why XP? – XP is a Mature Method
The SW-CMM has been developed by the software community
with stewardship by the SEI.
past experiences in process improvement such as TQM
academic business theories
practical experiences of successful projects gained from companies
such as IBM
The CMM has five levels of process capability maturity.
129
Why XP? – XP is a Mature Method
The first – undisciplined:
processes may be loosely defined and rarely understood.
estimates of cost and schedule are poor and consequently projects have
serious problems meeting deadlines and functionality requirements within
budgets.
management generally is unaware that processes exist and often makes
decisions that hurt more than help.
130
Why XP? – XP is a Mature Method
Level 2 - Repeatable:
puts project management practices such as requirements definition,
configuration management, and quality assurance in place that are
documented and can be repeated.
Level 3 - Defined:
graduates the best practices of individual projects to an organizational
process.
adds concepts of organizational training, process management, and
program management.
131
Why XP? – XP is a Mature Method
Levels 4 and 5:
use information and measurements defined in levels 2 and 3
to understand why the process behaves the way it does so
it can be improved.
Level 5:
the process is mature enough to prevent defects instead of
reacting to them and to insert new technology and process
improvements knowing exactly how the organizational process
will be affected.
132
Why XP? – XP is a Mature Method
The CMM has become popular around the world because of
its ability to be applied practically to any software
environment.
It describes what process components should be in place
(such as recording requirements, planning and tracking
activities, estimating, etc.), but not how to implement them.
eXtreme Programming fits as a framework for “how to
implement the processes”.
133
XP in practice: Success and failure
3 Sep, 2002: XP - An interview with Kent Beck
Q: What are the issues you see your clients struggling with?
KB: One of the issues is redefining failure or redefining
success. For example, you think that you have a great
idea for a project, and it's going to take you nine months to
really have it ready for the market. You [may] discover
after four weeks that you are going one-tenth the speed
that you thought you would, and you cancel the project. Is
that a failure or success? In many organizations, this is
perceived as a failure.
134
XP in practice: Success and failure
3 Sep, 2002: XP: An interview with Kent Beck
KB )cont’(: In the XP world, providing information that allows you
to constantly make that decision after four or eight weeks (out
of a nine-month development cycle) is what you're there for. In
the XP world, you call that a dramatic success. Now you have
this cultural mismatch between how outsiders are going to
view your outcome and how you view it inside the team. A lot
of people [clients] struggle with that. They think that canceling
a project is a bad thing, but I think that canceling a project is a
good thing -- as long as you cancel the right one.