by Ron Jeffries, Ann Anderson, and Chet Hendrickson
Chapters 10 - 12 of Extreme Programming Installed make the transition from design and planning to the actual task of programming for the user stories. The first step is to have a quick design session, designed to eliminate the fear that you may not know what to do. This design session shouldn't last more than 30 minutes, and usually consists of drawing a few UML designs, or talking about different implementation possibilites. But, usually the best thing is to get started programming right away; it's hard to know exactly how anything will work or how you will build the system until you sit down and start programming.
A key aspect of XP programming is that the code is owned by everyone in the programming team. Even if you created a class, anyone else can make changes to it. In this way, if a class you're using isn't exactly written the way you need it, you can change it yourself, instead of having to go through the creator. The way that this system works without a lot of conflicts is that the programmers release their code often, sometimes up to three times a day, and each time they make a change they run unit tests. These unit tests must always pass 100%, and the programmer must fix all the errors and make all tests pass before they release. In this way, conflicts between programmers changing the same file can be found and addressed quickly. Another aspect of XP programming is that we program exactly for the specifications, and as simply as possible. We implement the minimum number of methods, in the simplest way possible, commenting the code and naming functions and variables to make it easy for anyone to understand the code. In this way, it makes it much easier to come back and add new methods or edit the way a function returns data. This also means that the programming team must have a coding style standard for indentation, naming, capitalization, etc to make the code easier to read.
The biggest change from traditional software development in XP programming is "pair programming." In pair programming, all code is written by a pair of programmers working at the same computer. When two programmers are working together, they end up producing more code, don't get tired as faster, and two people understand the code rather than just one person. There are two roles in this paradigm: driver, and partner. The driver is the one typing the code on the computer, and has most of the general algorithm in their mind. They are responsible for keeping the partner engaged, explaining the code as he goes. The partner is responsible for watching the code for typographical errors, making sure the driver is following the algorithm correctly, and making the driver clarify and fix things that are hard to understand. Driver and partner should switch roles often so they don't get bored or stale. Using pair programming, the programmers work much more efficiently, get a lot more work done, and stay engaged easier.
The idea of collective code ownership seems like an extremely good idea to me. When you know that you can always fix all the problems that are in the way of your code development and make other pieces of code work for you, you can finish your code much faster. The only problem is minimizing conflict between intentions and other programmers' code. While they say that you can manage this by testing and releasing all the time, it still seems like two programmers could change the same thing back and forth without agreeing on a solution they can both use. Pair programming also sounds awesome; I know that when I'm working on code I have problems staying engaged and always working. With another person there, they could fix my mistakes much earlier and keep me on track.
No comments:
Post a Comment