Session 10
Project Development
810:188
Agile Software Development
And They're Off!
Everyone paired off, checked out a copy of the project
repository:
svn checkout https://student.cs.uni.edu/svn/810188-May10
... grabbed a story, and started writing a test. After two
hours or so, the result was ten new revisions to the repo
and a few implemented stories. They are simple stories, and
future features will require modifications to the code the
team produced, but this is a good start.
Another result was a few lessons learned:
- Sometimes, implementing two stories can result in major
collisions. This is especially true at the beginning
of the project, when every change is a large change
relative to the size of the code base. To the extent
that collisions are an unavoidable result of the state
of the project, the team needs to be aware of the
possibility and be prepared to communicate their
design decisions to other pairs. To the extent that
collisions are the result of story selection, the team
may be able to avoid them by communicating more at the
time they choose stories to implement.
- The team needs to make collective choices about team
standards, whether for code (say, common naming
conventions for factory methods) or for design (say,
how the program should behave when it is unable to
create an object in a particular situation).
- The team has plenty to learn about Ruby yet. Today,
we learned about
how to simulate overriding methods
and how to handle situations in which a
constructor should fail.
We discussed one other practical issue that will likely arise.
What happens we implement some feature in the future, and the
result is incompatible with existing tests and other objects?
An example is Account.examine, a fairly simple
method at this point in time because Accounts are
simple objects. What do we do to fix it: let the team that
implements the offending code, resurrect the old story, or
create a new story? An even bigger question is, How will we
even know about the incompatibility, or the broken tests?
These are good questions and lead us to study another
element of agile development: continuous integration.
Wrap Up
- Homework. None.
- Reading. Read Martin Fowler's paper,
Continuous Integration
to learn a bit about why members of a team should integrate
their work into the full system frequently, supported by
an automated build and test process.
Then, read a bit about
Rake,
a simple build program in Ruby that has capabilities similar to
the common Unix tool make. In particular, look at
Martin Fowler's
Using the Rake Build Language
and Jason Seifer's
Rake Tutorial.
This papers talk a lot about dependencies between code files,
which we have already see: GeneralJournal depends on Transaction
and Account. Just as important for us is that we can use a rake
script to run all of our tests every time we integrate code
into the working system.
- Programming. Keep learning Ruby, especially any language
features you encountered today but didn't understand well. You
may also work on the team project but only with a partner.
We will continue to do pair programming for all team code.
Eugene Wallingford .....
wallingf@cs.uni.edu .....
May 21, 2010