Slashdot Mirror
Java Tools For Extreme Programming
In recent years there has been a increased emphasis on Agile Software Development. The most prominent of these methodologies is probably Extreme Programming.
What sets Extreme Programming apart from most other Agile Technologies, in my opinion at least, is that it has provided practical, easy-to-use tools to support its way of working. Most of these tools (Ant, JUnit etc) are Open Source and freely available. However popular these tools have been with the Open Source and Extreme Programming communities, it has arguably been difficult to introduce them to traditional IT development environments. This has been primarily due to the problems of justifying spending time on 'playing' with something and the difficulties of retro-fitting new tools to an existing development environment (think projects of 150+ people which have been releasing for 5-10 years for some idea of the potential problems).
It's worth noting that when embarking on a new, large-scale project it's very difficult to find a book discussing the issues of controlled builds, integration and deployment in practical terms. The most valuable aspect of Java Tools for eXteme Programming is that it's alone in its market niche.
The book is mainly useful as (a) an introduction to the various building and continuous testing tools out there and (b) a tutorial to getting them setup and working on your computer. As the authors note, there's a critical period where the user must get some result after playing with the tool for a short period of time or just give it up as 'too difficult.'
From a technical standpoint the book is very readable, but it doesn't tackle any one subject in great depth. It certainly provides enough information to get you up and running, and also, perhaps more valuably, illustrates how to integrate the tools together. It's an excellent primer for those who want to use the tools but are unsure of how exactly to start.
What's covered? Here are the chapter headings:
- Introduction and Key Concepts
- Introduction to Extreme Programming
- J2EE Deployment Concepts
- Example applications
- Mastering the Tools
- Continuous integration with Ant
- Building Java Applications with Ant
- Building J2EE applications with Ant
- Unit testing with JUnit
- Testing Container Services with Cactus
- Functional Testing with HttpUnit
- Measuring Application Performance with JMeter
- Load Testing with JUnitPerf
- API and Tag Reference
- Ant Tag Reference
- Ant API Reference
- JUnit API Reference
- Cactus API Reference
- HttpUnit API Reference
If you use some of these tools already will you learn anything? Probably -- I personally have been using JUnit to test EJBs for almost nine months now but didn't know about JUnitPerf or Cactus.
Should you buy it? If you're new to the tools, then Yes. If you work in a professional but traditional IT shop, I'd buy one for the group (I have). It'd be particularly useful when dealing with management and proposing changes to working processes, or when trying to bring co-workers up to speed and sell them the benefits of agile ways of working.
You can visit the book's website at Wiley. You can purchase the Jave Tools For Extreme Programming from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
My experience with extreme programming is that it is simply a bass-ackwards way of development.
The advocates of eXtreme pr0gramming who love to "refactor" their code on a daily basis seem to have the same mindset as the people in my upper level CS courses that would spend the entire weekend in the computer lab on their projects, and complain about their grades and the time they spent afterward.
I'd spend a couple hours making object relationship diagrams, program flow diagrams, etc beforehand. I'd show up at the lab Saturday morning at 9 and leave at noon, and the looks these students gave me were a combination of hatred, jealousy, and disbelief.
IMO, it's just a process choice. Planned, focussed development, or tinker-till-it-works.
This isn't a troll, or flamebait, its a standard old fashioned flame.
Peer Programming means continual review by two people, two bad people = bad code. 1 good + 1 bad = 1 slow average. Code review must be done by several people and must also include a senior resource to help less experienced ones.
This was also the tennant behind the Team oriented approach of the Mythical Man Month, which was based around the assumption of everyone should be good, just fire the rest.
XP is basically the re-hashing of some long held good ideas, interspersed with some total drivel from a bunch of hackers.
XP DOES say don't design the overall architecture of the system, it DOES say don't design how each service should work. It relies on the concept of Unit Tests where anyone will tell you that bad developers = bad unit tests.
XP is a sham and a fraud that is only allowed because the industry doesn't care about quality.
An Eye for an Eye will make the whole world blind - Gandhi
Intangeable? Bad software set a navy Battle ship adrift, how is that intangable? If software in medical devices fail and someone dies, are you going to tell there family it wasn't the softwares fault, its Intangable!
Whats that? a badly engineered software program lost all your customers account information? hey, its only computations, we can recompile it and fix it later!
The same METHODS apply to ALL forms of engineering. The fact that people have taken the we can recompile it and release a patch later mentality shows exactly how crappy the software development industry has become.
of course XP is a waste of time, because its not going to really catch on, It makes management accountable.
The Kruger Dunning explains most post on
Maybe you should read the books. There is nothing in XP against good design. What it isn't based on, however, is overdesign - attempting to design a system that will meet the (predicted) future requirements of the customer.
This issue of "hard" enginerring is clearly addressed. The point is that things like bridges, buildings etc, are not easy to alter once you have built them. If you find that the bridge was originally specified to be a footbridge and then the customer decides that what they really wanted was a road bridge, then it is very difficult to retrofit this new requirement. It has always been believed that software is the same - that changing it half way through is a very costly thing to do.
However, XP claims that with a good unit test harness, it should be, and in my experience is, very easy to change the underlying implementation of the code without breaking anything. You can't just rip out the entire ground floor of a building, but you can reimplement your decisioning code without the entire application falling down on you. This means that it becomes much easier to fit later requirements as and when they are needed. The XP project that I worked on had a major change to both the business requirements and, as a result, the whole way of interacting with an external system.
We had designed the package up front, but had designed it to do the requirements as they stood when we started. There was no suggestion to us of this other requirement at the start of the project, so no amount of analysis or clever design would have allowed us to code for it. However, once the new design was produced from these requirements, it was a trivial (1-2 days) task to recode several of the back-end classes to have the new flexibility in communication that was required (but with the same functionality). The unit tests allowed us to be confident that we had not broken anything. It was then another quick job to add the new functionaly, and we had a new working system.
None of this meant skipping design, or hacking. It just meant doing the amount of design that was appropriate at the time, and building a framework to allow us to change (hence "agile methodology") when requirements change.
You can't take a piece of a bridge out make it better and put it back in.
Um, well, actually yes you can.
They took out each segment of the bridge and replaced it with a new one. The work was done at night, with traffic flowing during the day. Quite a piece of work....
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
I don't have mod points today, so I'll just reply:
I don't think you could be more correct. You simply can't have a book about Java tools for XP without talking about IDEA and some of the other great refactoring tools out there.
IDEA has completely changed the way I write code. I never really took the idea of refactoring seriously until I found it. Until then, it seemed like the refactoring book was just a guide to the obvious, but to see the refactorings automated with names I immediately recognize made me rethink things. All those idealistic phrases I once laughed at started flooding back to mind.
With the exception of JUnit (and even that's a close call), I don't think any other tool supports XP as well as IDEA.