Transcript No Slide Title
Title Extreme programming for programmers
Kirill Kalishev SPb Java Users Group 13 Oct 2001
Contents
Key concepts Planning Design Programming Intent: to try to show programming in the eyes of the extreme programmer
The goals
Deliver value for the customer Flatten the change curve Have fun doing programming
Customer value
Conformance to a big up-front plan Start Planned result
Conformance to actual customer value Desired result
Change curve
Cost of change
Analysis Requirements Design Implementation Test We have to make it true!
Development lifecycle
Provided the change is cheap
Key concepts (XP values)
Communication
•
A project would fail if somebody doesn’t communicate
• • •
something important Simplicity Do the simplest thing that could possibly work
• (win in changing it when it needs change)
Feedback Optimism is hazard, feedback is treatment Courage Don’t let your fears stop you from making great software Values is what distinguishes bunch of individuals vs. team
Key concepts (four variables)
Cost Time Quality
Const
Scope
Manageable
The circle of life
Communication
Feedback
Simplicity
Courage On-site customer Pair programming Short releases Refactoring Unit testing Planning game Simple design Acceptance testing
Practices
On-site customer Planning game Metaphor Short releases Simple design Test first Pair programming Continuos integration Coding standards Collective ownership Sustainable pace Refactoring Weakness of one is supported by strength of others
On-site customer
The customer + programmers = a team The customer is in the same room to give answers
•
prevents programmers from putting their suppositions
• •
to code The customer is logically the one all stakeholders speak to programmers with one voice Can’t find a customer?
does the project make sense?
Talking to the customer everyday is a key to success!
Planning game - bill of rights
Customer Programmers The right to an overall plan (what/when/how much) The right to know what is needed (clear declaration of priority) The right to change mind anytime (functionality/priorities) The right to see the progress & be informed on any schedule changes The right to make & update estimates The right to accept responsibilities vs. having them assigned The right to get the most possible value out of each programming week The right to produce quality work at all times
Planning game - the moves
Customer Defines stories (on index cards) Programmers Say who much it costs (put estimates to cards), go spike if needed Defines what to do & what to defer (sorts by value) Sort cards by risk Defines the plan (by time or by scope) The plan Commit to meet the plan
Table
Planning game - yesterday’s weather
The team believes that the next iteration they will do the same amount of work as in the previous one
•
Project velocity in terms of ideal engineering time
• • (days/weeks/tomato hours)
is calculated All stories are estimated in the same metric Each next iteration is filled with the stories whose summary estimates fills the current velocity The worst problem is not being behind the schedule as such, but not knowing about that
Release vs. Iteration planning
Customer Planning game Programmers Release planning
• by scope/by time Release Iteration 1 2 n
Iteration planning
• by time (1, 2, 3 week iterations) • each iteration the project velocity is updated • task breakdown is done Release Iteration 1 2 n ...
Short releases
The whole team (customer + programmers) learns about the system
•
Releases are done often
•
The customer has a working system at all times
Acceptance testing
Customer Defines acceptance criteria for each story Programmers Make it automatic, make it pass
Design strategy
XP believes that the best strategy is to solve the most pressing problem while keeping most options In design, it reflects in the following:
•
No up-front design, instead,
• Do The Simplest Thing That Could Possibly Work • rely on your ability to change it later, when you learn new things or new features will be really needed • •
Do design all the time, as you go along Design for the iteration works Simplicity keeps most options!
On diagrams
Like drawing cool diagrams? Great! We like it too. However, Minimize the time between making design solution and turning it into code
• Computer does’t understand diagrams, but does it for code • You should consider yourself just guessing until code is written
Start with a test, to know when you are done
On architecture
Metaphor
•
The story both the customer and programmers share about how the system works Metaphor covers most of what we call “architecture”
•
System of names
• •
Actors Interactions PipeSegment
* 1 1
Plumbing
- Oops, it sounds like plumbing, right?
- Yes, something like that. In this case water going through pipes is like a transaction. When at least one valve is closed -- no way to proceed - Cool, why don’t we call it pipes, water & valves - Okay, sounds like fun *
Valve
Pair programming
A rule: Each line of code is written by at least two people Pair programming is a dialog of two people
•
The driver -
controls the keyboard, the mouse and actively • works on implementation of the program
The observer -
thinks more strategically, looks for errors, misprints & etc.
• Partners change roles
No dialog - no pair programming Pair-programmed code is better written & structured plus it is done quicker!
Acceptance vs. unit testing
Acceptance tests
•
Owned by the customer
•
Proves that the story is done in terms of the customer’s
•
perspective Unit tests Owned by programmers
•
Test everything that could possible break
• •
Written before production code Always pass 100% in the integrated code
Unit testing - a bet
You won’t win if you write a test that
•
doesn’t communicate any new things about how production code should work
• •
is not gonna break You will win if you write a test that communicates what is needed from the production code
•
will ever show that something has broken down
(which is • inevitable)
- Test Everything That Could Possibly Break independent of others as much as possible If you had to choose what to throw away, it should be production code, not tests
Unit testing - XP style
When to test? It is a normal way to program:
•
If you add a new feature, write a test before production
•
code If you fix a defect, write a test that would expose the
•
defect, then fix it Every time, before you integrate code, unit tests must pass 100% Don’t let the fear that testing can’t catch all bugs stop you from writing tests that will catch most bugs
Excuses for not testing
• • • • •
I don’t have time This can’t be tested I don’t know how It tests itself!
I already tested it once and I have not changed it. I am smart enough to know this works perfectly XP is not about writing production code. It is about writing tests and making them pass.
Code quality
Quality code
•
Runs all tests
• • •
Expresses every idea we need to express Says everything once and only once Have the minimum number of classes and methods consistent with the above No production production code is considered existing without tests for that
Collective code ownership
No code is owned by an individual person but
• •
The team owns that (read - everyone in the team) If you see the chance to put changes - just do it, all unit tests must pass 100%
• •
integrate asap, otherwise you will lose Why is it better than personally owned code?
You don’t have to wait unit a responsible person will be
•
available You know better what you want Conflicts are not a problem as such. You have tests, you integrate often so you are not afraid of conflicts
Continuos integration
No code sits nonintegrated for more than two hours
•
integration is not painful anymore, we do it several
•
times an hour!
There is only one integration thread a time to make sure you’re integrating only your changes (integration computer works) All unit tests must pass 100% every time you integrate
Refactoring
An activity of changing structure without modifying behavior, aimed at:
•
making the program easier to understand & cheaper to
•
modify A core activity to do a good program start with a simple thing & refactor it later. You are not
•
afraid of being wrong.
Refactoring essential? No, if you are omniscient
•
perfect
•
and so everyone else on the team Refactoring is everyday disciplined activity. If you do more and more refactoring - it means you don’t do enough refactoring
Essentials of refactoring
If you add a feature
•
first look for chance to improve existing code, to make the adding easier
• •
refactor make sure unit tests pass 100% & integrate
•
write a test, put in new feature and make the tests pass again
•
integrate If you see the chance to improve something - do it. Otherwise, you risk to run into debts.
If you don’t want to do refactoring for yourself, do it for your team!
Coding standards
Looking at the code, you should not see who wrote that Different coding styles should not be an obstacle to better understanding. Develop that, agree on that and follow that!
Any fool can write a program the computer can understand. Good programmers write programs other people can understand.
On comments
We do appreciate good comments. However, while development, we don’t write comments because:
•
they often lie
•
they don’t provide feedback (computer doesn’t
•
understand them!) there are a lot of more reliable ways to reveal the intent If you feel you should put a comment, refactor you program first. Then, take a look again. You are likely to lose you will to put comments.
Sustainable pace
Productivity does not increase with hours worked so we work 40-hour week to be fresh and eager If we have to work overtime, we don’t do it more than a week
On simplicity
Simplicity is the art of maximizing the amount of work not done
•
simplicity to do
•
simplicity to understand
•
simplicity to change Complexity is like debts. The more we keep it complicated, the more money we pay for that What may look simple for you, may not be the case for the team. The way is to learn, agree and follow. The whole team together.
On design patterns
Design is a kind of recognition of patterns - we call it “experience” Design patterns (like ones from GoF) give us system of names, what promotes better:
•
communication
•
understanding Since patterns are goals for refactoring, learning refactoring techniques is essential as well Thinking in patterns is not an evil. Narrow thinking is.
Why is it worth trying?
To realize if XP is for you or not
•
Practices are simple. Their interactions are not obvious. The most value on XP is in the mutual support of the practices To ship software & have from it
Who is who in the XP world
The inventors of XP
•
Kent Beck
•
Ward Cunningham
http://c2.com
• •
Martin Fowler Famous speakers & writers on XP Bob Martin
http://www.martinfowler.com
http://www.objectmentor.com
•
Ron Jeffries
•
Don Wells
http://www.extremeprogramming.org
• •
William Wake
http://users.vnet.net/wwake
Pair programming & collaborative development Laurie Williams
http://collaboration.csc.ncsu.edu/laurie/
Come share experience!
Within SPb XP users group
• http://groups.yahoo.com/group/spbxp
You can reach me
•by phone: +7 (812) 322-9526 •web: http://www.kirillkalishev.com