Date post: | 11-Jan-2016 |
Category: |
Documents |
Upload: | ira-barber |
View: | 221 times |
Download: | 0 times |
Topics
• Confidence - How does the team achieve and maintain confidence in the program?
• Communication - How does the team learn and remember?
• Design - How does the team maintain the life of the project?
• Coordination - How does the team make the best possible strategic decisions?
Today’s Purpose
• To enable you to adopt XP practices
• Goals to keystrokes - concrete things you can do
• Clarify, not debate
Topic Structure
• Philosophy - the general approach of XP to the topic
• Example - a demonstration of the practices
• Practices - 10 extreme things you can do
• First steps - what you should try first
Confidence Philosophy
• Tests are tangible confidence
• No program feature is done until it has an automated test
• Responsibility for testing is split between developers and testers
• Tests are run often
Confidence Example:Developing with Tests
1. Think of a feature
2. Write a test
3. Implement the feature
4. Run all the tests
Confidence Practices
• Fixture
• Assertion
• Alternative Logic
• Unit Test
• Functional Test
• Other tests…
Good tests
• Automated- comes back with a single answer
• Predictable- always produce the same result
• Isolated- failure in one test does not affect others
• Cheap- easy to write
• Stable- cheap to maintain
Fixture
• Predictable basis for testing
• Freshly allocated for every test
• Fixture used by a single test is initialized in the test method and stored in local variables
• Fixture used by more than one test method is initialized in setUp() and stored in instance variables
Assertion
• Call assert(aBoolean) to express expected value of an expression
• Call assertEquals(a,b) to express that two objects should be equal– Also works with long and double (add others if
you need them)
Alternative Logic
• Who watches the watchers?
• Get expected results from another computed source– Excel– Calculator– Published material– Existing system
Unit Test
• Written with a particular piece of logic in mind
• Best written before coding
• Responsibility of the developer
• All unit tests must run at 100% after every integration (several times daily)
• Ideally should catch all errors– Functional failures become unit tests
Functional Test
• Written with a particular story in mind
• Best written before coding (but be realistic)
• Expressed in customer-oriented notation
• When all the functional tests run, the customer should be confident about shipping the system
Other Tests
• Acceptance test- measurement of the fitness of the system for deployment
• Performance test- assertions about the resource usage of a test, not just its answers
• Stress test-simulation of the worst expected operating conditions
Tests in Practice
• Always keep the unit tests at 100%- if they aren’t, you don’t have anything more important to do than fix them
• Test answers, not implementation artifacts
• Graph functional test performance
01020304050607080
Week 1 Week 2 Week 3 Week 4
WrittenRunning
Confidence First Steps
• Write a unit test for existing code
• Write a unit test before implementing
• Run your test suite after integrating
• Ask your customer for functional test data
• Run two developers’ tests together
Communication Philosophy
• Face-to-face communication is best
• Exploit the source code as a medium
• Only produce valuable documents
Communication Practices
• Pair Programming
• Composed Method
• Simple Superclass/Qualified Subclass
• Role-based Variable Names
• Intention Revealing Method
• Double Dispatch
• Unit Test
Pair Programming
• Work two developers to a machine
• Write a test
• One thing at a time– Keep a to-do list of issues to be addressed in
the future
• Shift the keyboard when the other partner sees something wrong
Composed Method
• How big should a method be?
• Issues– Following the flow of control– Performance– Communicating “what” and “how”– Overriding
• Do one thing per method– Few lines– Consistent level of abstraction
Intention Revealing Method
• How do you name methods?
• Issues– Length– Parameters– Intention– Implementation
• Name methods after what they accomplish
Simple Superclass
• How do you name the root of a hierarchy?• Issues
– Long names are hard to read and format– Short names don’t communicate enough
• Use simple one word or two word names– Figure– Account
• In German, it is okay to use abbreviations
Qualified Subclass
• How do you name a subclass?• Issues
– Communicate about the superclass– Communicate the difference
• Prepend an adjective to the superclass you want to declare allegiance to– RectangleFigure– TradingAccount
Role-based Variable Names
• How do you name variables?• Issues
– Type– Role– Scope
• Name variables after the role they play in the computation– subject
Unit Test
• How do you communicate how an interface should work?
• Issues– Clear– Short– Easy to write
• Explain the interface with a unit test
Formatting
• How do you format code?
• Issues– Vertical space– Horizontal space– Block structure
• Adopt a common style
• Learn to read and write several styles
Literate Program
• Tell a story that includes each class and method in your program
• Between blocks of code, insert text and pictures that tie code fragments together– “Remember we said we would need
addMoney()?”– “With these pieces in place we can now
implement addMoney()”
Communication First Steps
• Pair program for two hours on a defined problem
• Rewrite code using the practices before fixing it
• Write a literate program
Design Philosophy
• Small initial investment
• Immediate feedback
• Continuous evolution
• Universal contribution
Design Example
• The JTest Framework
• Provides lots of leverage per line
• “Pattern dense”- you can see many patterns at work in a small number of classes
• Easy to extend
TestCase- Command
• It would be simpler to just send messages
• We need to queue up tests to be run later, so we can run them together
TestCase
Initialization- Template Method
• Different TestCase subclasses need different initialization
TestCaserun()setUp()tearDown()runTest()
setUp();runTest();tearDown();
Different Test Cases- Pluggable Selector
• Different TestCase instances need to execute different methods
TestCasefName runTest()
Method runMethod= null;runMethod= getClass().getMethod(fName, new Class[0]);runMethod.invoke(this, new Class[0]);
TestResult- Collecting Parameter
• Separately record results of test running
• Lightweight way to save history
TestCaserun(TestResult result)
setUp();try {
runTest();}catch (Throwable e) {
result.addError(this);}finally {
tearDown();}
Test- Interface
• Separate external specification of TestCase from implementation
• Allows for different implementations
TestCaserun(TestResult result)
Testrun(TestResult result)
Testrun(TestResult result)
TestSuite- Composite
• Run many tests at once
• Aggregate at higher and higher levels
TestCaserun(TestResult result)
Testrun(TestResult result)
Testrun(TestResult result)
TestSuiterun(TestResult result)fTests
System Metaphor
• How do you coordinate the design decisions of many designers?
• Centralized, detailed design offers control, but gives upinclusion and feedback
• Decentralized, piecemeal design can go out of control
• Choose a single metaphor for the system. Derive vocabulary and basic design from the metaphor.
CRC Cards
• How do you design when you don’t know what to type?
• Abstract design notations let you move fast, but accumulate risk
• Concrete design requires many detailed decisions
• Hold a 20 minute carding session. Include the responsible developer, other interested designers, and a customer.
CRC Card Examples
Money• perform arithmetic• convert to other
currencies
MoneyBag• perform arithmetic• convert to other
currencies
ExchangeRate• convert Money
from one currency to another
CurrencyExchange• convert Money to
specified currency
Spike Solution
• How do you design when you have too many questions to answer?
• You want to solve them all
• You can’t solve them all at once
• Build a system that operates end-to-end, but only for one test case
Refactoring
• Always work a little at a time
• Test between refactorings
• Don’t do anything dangerous– Tomorrow it may not be dangerous
Conditional -> Polymorphism
• Find repeated conditional code
Display() Visible: Invisible: Disabled:
Contains() Visible: Invisible: Disabled:
Visible DisabledInvisible
Visible DisabledInvisible
Static:
Dynamic:
Extract Component
• Find a subset of instance variables that only make sense with each other
...amountcurrency...
...money...
amountcurrency
Extract Component Steps1. Create class with extracted instance vars
2. Add instance variable to original classInitialize to an instance of the extracted class
3. Every setter of the original instance variables also sends setting message
4. Every access to original instance variables send getting message instead
5. Remove original instance variables
6. Move methods
Design First Steps
• Reach a design decision, then code for an hour each way
• Use patterns to describe your system
• Set a direction, then refactor towards it
Coordination Philosophy
• Business people make business decisions, technical people make technical decisions
• A little planning for setting priorities, more when the team needs details to implement
• Be prepared to refine and change the plan during development
• Clear rules• Frequent feedback
Coordination Example
• Play act– Story writing– Estimation– Planning– Iteration planning– Development– Recovery– New story
Coordination Practices
• Stories- Balance desires and possibilities
• Evolution- The plan learns, too
• Development- Execute the evolving plan
Business Justification
• How do you focus the early efforts of development?
• Create a simple projection of investment, payback and risk for five years
Year Cost Revenue Probability1 1.000.000 0 100%2 1.500.000 500.000 90%3 1.500.000 1.500.000 60%4 2.000.000 3.000.000 40%5 2.000.000 5.000.000 35%
Interest 5%Expected Value: -616.924
Write Story
• How do you learn enough about Business’ needs to plan?
• More detail reduces risk of missing something import, but slows process and adds inertia
• Write the stories the system must support as a name and paragraph on an index card
Story Example
• First release of Chrysler payroll started with 153 stories, growing to around 185 after 9 months of development
Ohio Union Dues
Employees at the Dayton plant pay $15/month union dues, except EIDs 48727 and 87728, who pay $10
Estimate Story
• How do you estimate the effort required by a plan?
• Interaction between stories can safely be deferred
• Estimate actively- build and discard prototypes
• Estimate on cards in “Ideal Engineering Weeks”- how long if you could just do it?
Commitment Schedule- Prepare
• Business sorts stories by priority– Must have or system won’t run– Contributes to business value– Nice to have
• Development sorts by risk– Know exactly how much work– Know about how much work– No idea
Commitment Schedule
• Establish velocity- developers * weeks / load factor (measure, mostly likely 2-3)
• Business deals out cards until target date is reached
• Put stories into 2-4 week iterations– Complete skeletal system after first iteration– Move risk and priority early– Not too much hard stuff at once
Recovery
• What do you do when your estimates are too low?
• First, examine your process to see if you can go faster
• Ask Business for minor reductions in scope that greatly reduce effort
• Ask Business to defer some stories
New Story
• What do you do with a new story?
• Issues– Development wants to be responsive– Development doesn’t want to be interrupted
• Do what you can do:– Business writes story– Development estimates– Business discards that many weeks worth of stories
Re-estimation
• What do you do when the plan is getting stale?
• No plan survives contact with reality
• Keeping the plan alive encourages communication with Business
• Re-estimate the stories remaining in the plan based on experience
Iteration Plan
• How do you plan in detail?
• Break the stories for an iteration into tasks
• Team members sign up for tasks
• Task owner estimates task in “ideal engineering days” (* load factor)
• If a developers has too much to do in the iteration, shift tasks around or redue scope – Do not reduce task estimates without a great reason
Development Episode
• How do you develop?
• Take a task card
• Find a partner
• If necessary, ask the customer for test data and explanation
• Cycle: Write a test and make it work
• Integrate
Continuous Integration
• How do you integrate development from different developers?
• To often and the overhead is too much
• To infrequent and trouble arises
• Integrate after no more than half a day or a day’s work on a task
• If the unit tests aren’t 100%, you broke them, so you fix them– Use a machine to single thread integrations
Coordination First Steps
• Write stories- use little pieces of paper
• Test/Code/Integrate in two hours
• Write game-like rules for changes to the plan