 |
|
^ click above ^ |
09.10.03
 By chromatic
Extreme Programming, or XP, isn't so much revolutionary as it is
evolutionary. Developers have known the value of code reviews, testing,
and good communication for decades, though we've ignored that knowledge
far too often in practice. Five
Lessons You Should Learn from Extreme Programming explained
several XP practices that apply to non-XP projects. A little common
sense, a bit of learning from failure, and a lot of discipline can
improve your team.
It's harder to see how XP can apply to open source projects, especially
those that apparently lack a formal customer and are generally immune
from budget and schedule pressures. The other challenges of software
development apply, though. Sustained development requires managing
complexity. To build a successful open source project, you must solve
many of the same problems you'd face with a successful in-house project.
As you'd expect, there are several lessons open source developers
can learn from Extreme Programming. |
1. Test, Test, Test
The second most valuable artifact in any project is an automated test
suite. (The first is the code itself.) Because few open source projects
have the luxury of pair programming or even mentoring with any reasonable
physical proximity, a good test suite is invaluable to understanding
the code.
There are two parts to a test suite. The first and most important
is the set of customer tests. Think of this as executable specifications.
The second part is the set of programmer tests. These exercise individual
pieces (functions, classes, and methods) individually. They're also
important, but secondary to the customer tests.
For example, in my Mail::SimpleList
project, customer tests simulate sent and received email messages.
That's it, I only need to mock up the system's entry and exit points.
From there, the essential, user-visible behaviors can be tested.
Examining the customer tests allows new hackers to get a feel for
how the system works and the features it supports. Anything not tested
doesn't exist. Don't count on it working in the next version. Don't
count on it working in this version.
The programmer tests operate at a much lower level. They're slightly
harder to write because they expose more details. They help immensely
while debugging, though, as they can often pinpoint bugs to certain
lines of code. As well, programmer tests help keep developers honest.
From the developer's point of view, a class, function, or method's
necessary behavior is enshrined in an executable test. You can be
more confident developing if you know that the tests will catch accidental
breakage.
The de facto testing tools in the XP world are all open source.
Given the existence of so many excellent open-source testing frameworks,
testing is the best place to start. Explore the appropriate testing
framework for your language. Write a new feature in a test-first fashion.
After all your tests pass and you can't think of any more tests to
write, refactor what you've just written. It takes a while to get
the hang of testing, but even a few naive tests are much better than
nothing.
Retrofitting tests to an existing project is difficult. Instead, write
a test every time you touch code, whether you fix a bug or add a feature.
This will concentrate your tests where you need them the most. As
a side benefit, after you've fixed a few bugs in the same section
of code, you'll likely have enough tests to refactor it; bugs tend
to congregate.
Of course, you need a well-designed system to get the most use out
of your tests. Test-driven development will help. So will the next
lesson.
2. Practice Simplicity
The Unix philosophy of writing simple tools that each solve a single
problem simply and can be combined easily and flexibly has worked
well for decades. Simplicity's not limited to operating systems. While
it's possible to go overboard, perhaps linking against dozens of libraries
to avoid writing a few lines of code, too many projects commit the
opposite sin.
XP promotes simplicity in two stages of the development process. First,
the scope of each release is kept small. Each release represents a
fixed amount of development time. Only work that is estimated to fit
into this time can be scheduled. Second, each development task is
implemented as simply as possible to pass the tests. No unrequested
features are added unless the schedule is readjusted.
Simplicity of Planning and Scheduling
Open source projects usually don't have the time or budget constraints
to require hard and fast release dates, but getting frequent feedback
from users and customers is vital to the survival of the project.
Since "customers" are often potential developers, having a good feedback
loop can increase the resources at your disposal. Keeping the source
code public with regular snapshots or anonymous CVS or Subversion
access helps, but if features take a long time to land or to stabilize,
it can be difficult to know when the code is worth using.
As with in-house projects, soliciting feedback and scrutiny can be
scary. It's integral to solving real problems correctly, though.
Freeware mail server
Hi there
I am looking for a reliable, stable freeware email
server software like FTGate. Any suggestion?
|
|
|
Anyone can come in to the code at any point, so keep the code accessible.
Keep the main source tree passing all of its tests. Fix any problems
as soon as they occur. Several large projects, including Mozilla and
Perl, have regular smoke tests that run the full test suite as often
as possible on as many platforms as possible. It's much easier to
track down errors if you can narrow down the breakage to a single
change or set of changes. (Andreas Koenig has a script that finds
previously unknown regressions in Perl by performing a binary search
on changesets. It's very handy.)
Work in steps as small as possible. Minimize each set of changes.
Not only is this less to test and less to debug, but there's less
migration between changes. Watch how Linus manages big changes to
the Linux kernel; he prefers small, steady patches. They're easier
to read as they change one thing at a time.
By working in small steps, it's easier to have regular releases. Subversion
is a good example. While they have goals for beta and final releases,
they release a new snapshot every three weeks. Scheduling releases
can be difficult, with random contributions, but the bulk of development
likely comes from a few, dedicated coders anyway. You can't control
what outside developers produce, but you can focus their contributions
into small, manageable pieces.
Simplicity of Development
A small, simple application that does one thing well is much more
valuable than a hundred applications with lofty goals that never actually
do anything. There's nothing wrong with writing a framework, provided
you really need it. It's much easier to generalize a framework out
of working projects than to design a framework to fit future, uncoded
projects.
A few projects have survived despite going the other way around. Mozilla
comes to mind, giving the appearance of building everything but a
decent web browser for a couple of years. Don't count on a combination
of luck, skill, funding, and determination pulling you through.
Practicing simplicity can be difficult. Test-driven development helps,
at least when you're implementing a feature. It's harder to design
features simply. If you have other developers, talk about upcoming
features and try to find the simplest way to implement them. It may
take a couple of rounds of brainstorming on IRC to find a better approach
than any one person's best idea, but it will happen.
Click
Here to Read the Full Article
*Originally published at O'Reilly
Network
About the Author:
chromatic is the technical editor of the O'Reilly
Network, specializing in programming, Linux®, and open source
development. He's also been known to evangelize to his co-workers
toward better development practices. chromatic has been known
to produce startling numbers of test suites---and a few testing
modules--for a few projects, including Perl 5, Perl 6, and Parrot.
Someday, he'd like to claim some responsibility for improving
the quality of all software, by writing articles, producing
good code, giving interesting talks, and developing better tools.
He lives just west of Portland, Oregon, with two programmers,
one cat, and a backyard full of surprisingly pleasant swamp.
|
 |
Read this newsletter at: http://www.linuxpronews.com/2003/0910.html |
|
|
|
View
Post
Click
To Comment