eXtreme programming

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


על-סמך ניסיונכם עד היום בפיתוח

תוכנה:

מהן הבעיות המרכזיות המאפיינות

פרויקטי תוכנה?

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


מה אתם יודעים עלXP?

8


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


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




On-site customer

Customer’s on-going

feedback

Small releases

On-going opportunity to

update/change

requirements

16




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


Round 1:


Why eXtreme Programming?


Round 2:

What is eXtreme Programming? Further details

Why eXtreme Programming? Further analysis

How eXtreme Programming? Further elaboration

24


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


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


A cooperates50%20%

A competes80%0%

39

The Prisoner’s Dilemma: The case of software engineering – A’s perspective


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


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


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


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


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


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


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.


83


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


Fourth step: Create subclasses of the extracted

class and initialize the instance variable to the

appropriate subclass.

Adding subclasses of presentation style

85


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


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?


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


How refactoring?


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


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


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:


Why refactoring? OK

When refactoring? When not? OK

How refactoring?


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:


Why refactoring? 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


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


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:


Why refactoring? 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:


Why refactoring? 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


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


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


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


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


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.