Early Stages of a Program
Test first. Use RAD tools. Don't optimize early. There's lots of advice for the early stages of a program.
Today's issue of java.net includes posts on each of these three items. We are featuring a chapter excerpt from Johannes Link's book "Unit Testing in Java How tests drive the code". Publisher Morgan Kaufmann gave us permission to post this pdf excerpt from the book that focuses on test driven development of GUIs. Often GUIs give new TDD developers a tough time. How can you test that a GUI does what it's supposed to do without bringing it up on the screen and playing with it? Johannes presents what he calls "The Direct Way".
This is the first time we've used a pdf of a book excerpt. We weren't sure how to best handle it. We didn't want you to click on a link and find yourself downloading a pdf without warning. We also wanted to give you a chance to provide talkback on the content as you can with every other article. So Sarah and I decided that the HTML would be a small introduction to the article that made it clear that the link is a pdf. If you have suggestions for how we can handle this in the future, feel free to drop me an email at email@example.com .
Today's Weblogs begin with James Gosling's entry Is it ever too early to optimize? James acknowledges that his bias probably stems from having "learned to progam on a machine with only 4K of RAM." Given the availability of cheap RAM and faster machines, we don't always design with enough attention to "cleanliness". He explains
In the "no premature optimization" model of the world, you ignore performance and build your system as cleanly as possible. Then you measure and tune. But after the tuning is done you can still find that the system is slow, but there's no real performance problem that you can localize. It's just a generalized, diffused slowness. A lot of small things spread everywhere that add up.
There are times that you need to consider performance from the start. One example that Gosling offers is "if you were building an editor for 3D models, almost all parts of the application interact with the model data structure. You can do a lot to hide the details, but there's only so much you can hide. If you don't think hard about the data structure right at the beginning of building the application, you're likely to end up with big problems. "
Philip Brittan gives his take on a similar issue in his post RAD Tool Let-down. He writes that RAD tools are appropriate for getting a prototype of an application but that
building the GUI through code does have some big advantages, and, personally, I almost never use a GUI builder for a production application. Here