xp practices

8/3/2019 XP Practices

http://slidepdf.com/reader/full/xp-practices 1/30

Department of Computer Science, University of

Sheffield

eXtreme Programming - Practices

Dr. Marian Gheorghe




Sheffield

Pla

n• Example• Practices • Conclusions




Sheffield

Example: Customer/order subsystem Enter customer details (name, reference,address, phone, email); validate; edit Enter orders by customer (customer reference,order reference, order details, delivery date,

invoice reference); validate; edit




Sheffield

Story cards 1.Story name: Enter and validate customerdetails

Task description: enter customer details andvalidate (ref. unique, name alphanumeric,

phone numeric, address non-empty); if validrecord then store it otherwise re-enter it. Initiating event: a request made throughchoosing a menu option



Story card cont’d Memory context: customer records exist and

will

be updatedObservable result: confirmation of success or prompting an error otherwise Related stories: Edit a customer details

Notes: Mandatory Risk factor: 1(low) / Change factor: 1 (low)


Sheffield




Sheffield

Story card cont’d Functional tests Customer with a new reference, arbitrary databut alphanumeric name, non-empty address,numeric phone Customer with an existing reference Customer with either non-alphanumeric name orempty address or non-numeric phone Customer with empty fields (name, referenceetc)




Sheffield

More story cards: 2. Edit customer details (validation included) 3. Enter and validate orders by customer 4. Edit orders (validation included)




Sheffield

The twelve sacred tenets of XP 1.Test first programming Functional test sets; from story cards

Unit test sets (white-box:branch/condition/statement coverage) Non-functional requirements tested




Sheffield

To get used to testing continuously – Run unit tests every time a newmethod/function has been created Run functional testing every time a new class,or set of functions implementing a story card




Sheffield

2. Pair programming Any work involving code is done in pairs: twopeople – one computer




Sheffield

3. On site customer: N/a 4. The planning game Story cards + cost estimations (how long it takes,how many people involved) Story cards discussed with the client Test sets associated with will help to understand

some tricky conditions/new aspects; ask the client




Sheffield

5. System metaphor A read.me file with the file structure of theproject + a short description of the components An X-machine model of the system/subsystem



X-machine specification


Sheffield

customer_proc

end_customer

pick_up_customer

end_customer

order_proc

end_order

exit




Sheffield

X-machine model State based model (states in green); with an initialstateTransitions labeled by function names The model may contain functions which

themselves will become X-machines (blue ones)

Hierarchical model




Sheffield


Sheffield

customer_proc:

click_customer

edit_customer

search&display

change_customer

enter_customer enter_detail

validate_data

error

success

end_customer



Function component Takes an input (click a button, enter some data)

and a memory value then produces an output and updates the memory side. Formally: func_comp:: Input x Memory -> Output x

Memory


Sheffield




Sheffield

Function components (examples) click_customer:: customer_btn x λ -> λ x customer_sel

enter_customer:: enter_btn x customer_sel -> λ x customer_sel enter_detail:: data x customer_sel -> data_echoed x data

where data =(name,reference,address,phone,email)




Sheffield

6. Small, frequent releases Releases are not prototypes A release implement a couple of stories A release is thoroughly tested Releases are related to




Sheffield

7. Continuous integration Write small units and test them (unit testing) Integrate into the system and test itfunctionally (test first programming) Suggestion: one pair be responsible forintegrating components into an operational

system




Sheffield

8. Keep your code as SIMPLE aspossible If it’s not so simple then…




Sheffield

9. Refactoring Restructuring the code without changing its

functionality

Its main use is to simplify the code (Fowler) -moving methods used in several classes in anew one • renaming classes, methods, functions

• simplify conditional expressions;

reorganise data




Sheffield

Refactoring (cont’d) Refactoring the test sets accordingly Changes into code require test sets changesas source code and test sets are the two maindeliverables




Sheffield

10. Code standards Should follow consistent class/method namingconventions Study coding standards before startingprogramming; decide upon a set of rules; showit to your manager Similar conventions should apply for test sets,story cards, metaphor

11 C ll ti d hi




Sheffield

11. Collective code ownership Coding standards help in using the sameprogramming style Changes might be done by everyone in theteam Suggestion: keep commenting your code withname, date and what has been changed;

provide a change notification form Changes in the documents/story cards will bereflected only in notification forms and CVSvariants.




Sheffield

12. 48 hours/week =>

avg of 15hours/week Use your time adequately




Sheffield

Java coding standards(p.131-) Each directory containing java files will containa README file describing briefly these files Each java source file will contain a singlepublic class or interface • beginning comment: class name, author,

date, version, changes description,changes history

• a specified class structure




Sheffield

Java coding standards(cont’d) Each method should have a commentassociated with Block comments vs single line comments One declaration per line + comment One stmt per line (simplicity) Layout for class decl, if, for, while, switch, trystmts




Sheffield

Coding standards Decide which standards you apply Apply them consistently (you’ll be marked onthis basis!) The standards are there to help you produce

simpler and easier to understand code




Sheffield

References K. Beck, “Extreme programming explained.” Addison-Wesley, 1999 K. Beck & M. Fowler, “Planning extremeprogramming.” Addison-Wesley, 2000 M. Holcombe, “Extreme programming for real: a

disciplined, agile,approach to software engineering”,2003 M. Holcombe & F. Ipate, “Correct systems: building abusiness process solution”, Springer, 1998.

S




Sheffield

Summary Are the 12 XP practices all applicable to SHprojects? Simplify/apply partially some of them Enforce others Strengthen the testing side

xp practices

Documents