1 von 1 Kunden fanden die folgende Rezension hilfreich
A new approach to software development,
Rezension bezieht sich auf: Extreme Programming Explained: Embrace Change (Aw Professional) (Taschenbuch)
This approach to programming was much bandied about and a little controversial at a software engineering conference I recently attended. Beck's premise is to take proven good practices in software development and max them out:
- if code reviews are good, do code reviews constantly by having another programmer look over your shoulder.
- if testing is good, write your test plans first and then test each time you implement another feature
- if integration is good, integrate almost constantly so that the system always works
The underlying premise is that the old, familiar cost curve that says it costs a thousand times as much to fix a mistake in the testing phase as in the requirements phase is no longer accurate: we have much better tools now than when that curve was formulated, we're living in Internet time, and the customers don't know what the heck they want anyway. So we might as well go ahead and try to give them something, then fix it up later, rather than trying to divine their goals now.
The problem I see with this is that there's not much time allowed for doing analysis and design. Beck specifically counsels against trying to anticipate capabilities, but if you know what you're doing, anticipating capabilities can save you a lot of time down the line. (His rejoinder is that it can also cost you a lot of time in implementing and debugging features that don't work and may never be used.) No matter how clever you may be, doing design as you code seems to me to be one cut above the worst sort of hacking.
Still, there are some marvelous ideas in here: pair coding sounds intriguing, writing test plans first is a must-have, and I've always held the position that the system should be constantly integrated, that there should never be a big push at the end to get all the pieces to fit together.
He also has other, related advice: developers should not work overtime for more than one week in a row (that's a way to become less productive, not more), you should have a customer representative onsite with the programming team to answer lesser questions about how to implement capabilities, and so on.
In summary, this book is very worthwhile for anyone who wants to improve their software development practices (and who doesn't have problems with their software development practices?). It's particularly good if you're in an environment where the customer wants a quick response to what they want when they want it even as they're not sure what they want. I wouldn't recommend adopting the approach wholeheartedly and automatically (and neither would Beck), but take what makes sense and go from there. As Beck himself says, figure out where your biggest problem is and adopt XP practices there first.