Slashdot Mirror

Automated testing allows developers to let the software decide what's broken and what isn't, so the developer isn't spending 75% of the coding time staring at 20meg log files looking for the line that is wrong, on every run. It also improves design because it requires the programmer to have already decided what the "right" answer for an algorithm should be, thus the algorithm is properly designed to completion.

Refactoring became very important -- its critical for developers to learn how to change and improve what's already working to create code and designs that are cleaner and easier to work with for extensions and new features. I've found refactoring can do wonders in solving problems that would otherwise have had to have been dealt with by Brooks' philosophy of "Throw the first version out". With refactoring, you can save much of the code / algorithms of the first version while still throwing away the faulty architecture that is making extensions difficult; you can learn to not be afraid of changing code that works.

I'd love to give the book to every graduating CS major looking into a programming job, since the first thing they're given is a "hey, fix up this code" job, usually.

I use emacs and JDE (discussed in other comments here) for my own work, including on Windows platforms, but if you go for a commercial IDE, there are plugin extensions for some IDEs (including Borland's JBuilder) that are made to embed JUnit and refactorings into the IDE; you'll see pointers to them on the web pages.

Never been posted about on /. before, that's for sure!

http://slashdot.org/books/00/12/29/1653211.shtml
http://slashdot.org/books/01/01/30/044210.shtml
There are actually 5 books so far; do a search for Extreme Programming on Amazon. I've only read 2, since 5 is an awful lot for any programming philosophy.

Well, to sum up all this: yes, the 2 coder approach can work quite well. It seems like work, but try it on some real stuff-- it's generally more productive than 2 coders working separately, especially when you count bug fix and QA time.

Another Extreme Programming philosophy is test often, and one popular way to do that is using JUnit tests.

We've been using the JUnit tests with great success. We haven't been doing as much pair programming, though I'm not sure why-- whenever we do it it kicks a lot of ass.

I'm sure someone here can give a better summary-- one or two of the authors of some of the Extreme books post occasionally. I'd be rather surprised if any coders here hadn't heard what I just posted above-- if you haven't, what rock have you been hiding under?

It's called refactoring, actually. Incremental redesign. Check out Refactoring : Improving the Design of Existing Code. Also note that you have to have excellent unit tests. Check out junit

Personally, I'd use some sort of scripting environment, probably Perl, for all of the prototyping, playing around, data translation, and glue work.

And then for serious stuff, I'd use something more structured and formal. Personally, I like Java; it's well known, pretty well supported, good at handling errors, has a reasonable amount of network stuff built in or available, and from the beginning had threading in mind. But I would certainly use some sort of OO language for this, as this kind of work strikes me as well-suited for an OO approach.

Oh, and do your work incrementally! Avoid grand plans; code in an exploratory fashion. If you're doing OO work, the book Refactoring is a great one. And if you're doing incremental design in Java, you will soon grow addicted to unit testing; I have grown to love JUnit, a Java unit testing framework.

But if this is mainly for your own use, use whatever tools you are most familiar with. I find that tackling a new tool and a new problem domain at the same time is generally too much to allow quality work. New problem? Old tool. New tool? Old problem first!

I'm currently building some server-side Java web applications. Since the Java Servlet stuff is inherently multi-threaded, I have indeed occasionally been reminded that multi-threaded applications are tricky.

A few months back, we purchased a suite of tools from an outfit called Sitraka (nee KLGroup). They have three products that are part of the JProbe Suite, a CPU and memory profiler, a thread analysis program, and a code coverage tool.

These are all good tools; when I was having some problems that I suspected were due to my less-than-perfect understanding of threading, I used their thread analysis tool under simulated load, and it immediately identfied my race condition, plus a couple more potential races I hadn't noticed yet.

(This is a little off-topic, but I have to mention that their memory/CPU profiler is, pardon my french, fucking awesome; it is the best thing I have ever seen for visualizing the interior structure of a running program. After a day with the profiler, my Java code was substantially faster than the C it was replacing, despite having more features and being more secure.)

Another tool I'm very pleased with is JUnit, a unit-testing framework. If you're interested in trying out the Extreme Programming-style approach to testing (wherein you make automated, integrated unit tests that are run more or less continuously) then this is for you. And if you are having so many problems with bugs that you are considering changing languages, then I would strongly recommend that you do this. Good unit tests slow initial writing down a little, and save you extraordinary amounts of time and agony later.

Oh, and run out right now and buy several copies of Code Complete and Rapid Development for the team. If you are having such large problems on the project, the problem is probably not with your choice of debugger. These books will help you figure out what the problem actually is, and give you all sorts of solutions.

--

For the record, and I don't have any financial interest in any of the things I've mentioned here; I just use 'em and like 'em.