Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000
Summary
Chapter 10 briefly describes what the authors term a 'Quick Design Session'. It is used on an iteration when the team is unsure of how to implement certain tasks. The design session should only encompass between 10 and 30 minutes, with the first couple of minutes being the most important since that is when most of the breakthrough and understanding will come. In the meeting, the team should quickly sketch out the simplest design that is likely to work and then immediately proceed to coding.
In chapter 11, entitled simply "Programming", discuses the various considerations that must be taken during the actual coding process. All code should be written in pairs, accomplishing one task at a time. Before writing any code, the pair should write the unit tests for that task including all tests necessary to ensure that everything that could break is tested. When the pair is finished implementing a task, the tests should be run and then the code should be integrated back into the repository so the rest of the team can make use of it. This process is called continuous integration, and ideally there would be multiple integrations a day to keep every team member up-to-date with the latest working code. The longer the time between integration and acceptance tests, the worse it will be since the peculiarities of the code will be forgotten. A key part of this programming paradigm is the concept of code ownership, or rather, the lack of code ownership. Any team member can edit any code in the system because each team member must understand how the whole system works. To facilitate this, a team-wide coding standard must be used encompassing indentation, capitalization, commenting (or lack thereof), method size, and naming. Commenting should be kept to a minimum by making the code's intention as plain as possible so that comments are unnecessary. The design of the program should be as simple as possible, following these principles: passes all tests, expresses every idea needed, no duplicate code, and the minimum number of classes and methods required. Refactoring is a useful tool for taking a complicated design and making it simpler while still maintaining functionality.
Chapter 12 focuses on pair programming in practice. The benefits of this system over individual programming is generating more and better quality code and that two people instead of one will fully understand the code. The programmer doing the actual coding is called the driver, and the other is called the partner. The partner is supposed to help spot errors and fallacies in the code, generate ideas, give feedback, and help with whatever the driver is doing even if he thinks there may be a different way. Consequently, the partner must be fully engaged in the programming process. The driver must keep the partner up-to-date on what he is thinking to keep them fully engaged, and to accept feedback from him. The least sure person should be the driver since he might become completely sidelined as the partner by not contributing because of lack of understanding. Finally, the driver and partner need to switch places occasionally to keep both interested and involved.
Opinion
The only useful bits from these chapters are the length of the design meeting (which is surprisingly short), the use of pair programming for all code, and writing tests before implementation. Writing tests first implies that the programmer knows exactly what design he is going to use, which seems unlikely to stay the same in practice, therefore he will have to update the tests quite a bit as well. Using pair programming is an interesting concept and I wish we had made use of it in class for a project to gain experience.
Pair programming in action
No comments:
Post a Comment