Extreme Programming in St Louis
Went to the XPStL meeting last night, to hear Brian Button talk about refactoring, a key part of Extreme Programming, also known as XP. Extreme Programming has absolutely nothing to do with Extreme Ironing. Really interesting talk/code walk through/lesson/discussion, and the cookies were pretty good too.
Normally, programming starts with design, then you write the code, and then you test it. This is how I wrote Chronicle, and it works OK. The XP way of programming starts with writing the test, then you code something to pass the test, then you refactor it. You work in pairs, two programmers to each computer, taking turns at the keyboard. It sounds crazy, but an XP team ends up with up to ten times the output of a normal programming team, writing better code and fewer bugfeatures. You also get up to date documentation in the form of unit tests and acceptance tests, so long as you can read source code.
Brian Button demonstrated refactoring by adding a tiny little feature to an existing open source project that he said was pretty well coded for non-test-first code. It took him "one perfect day," which amounted to four days of tearing his hair out. He wrote nine tests to insert 20 or so lines of code. Nine! I have a better idea now of how to test, and what mock objects are, and why they're useful for testing. But having seen him work through this code, I feel sorry for its creator, and I hope he never stumbles on my code. The object model had some weird stuff in (concrete base class, abstract child class inheriting from it, and another class inheriting from the abstract one) and looked as if he bolted on features partway through development. I'm guilty of that too, and of a whole pile of other coding sins. Mr Button says he's a very gentle pair programming partner, but it sounds gut-wrenchingly embarrassing to watch someone reaming out your code and putting better stuff in its place.
Then there's the refactoring. Refactoring is what you do after the code fails the unit and acceptance test, and after it passes. It requires going back into the code, stifling a shudder at what you just hacked together, and making it less shudderworthy. Hubby has already refactored Chronicle up, down, and sideways, cutting the start up time in half. Right now I'm not 100% sure which bit of code does what, and I need to go through the whole thing line by line to find out.
So now I have both guilt and ambivalence. I've never written test-first code, and I know Chronicle could be a whole lot better. Do I rip Chronicle apart and rebuild it as test-first code, thus hopefully improving the quality and adding JUnit, Eclipse, and IntelliJ Idea to my list of skills? Eclipse is a free Java IDE, but I think I know enough not to be lured to the Dark Side and depend on the IDE to write my code for me. Or do I stuff the guilt and wrap each new feature in tests as they get added, and theoretically improve the program as a whole by polishing parts of it?
Chronicle is my "I really need to learn Java" project. It's supposed to end up as a blog manager to replace the one I'm using now. In its current state, it can load and save entries, update and delete them, display both a calendar display and a tree display of existing entries, cough out XML and parse it into HTML/PHP for upload, it has theme support so you can make it look pretty, user config, albeit in an XML file you have to find and hack yourself, and it uses an hsql database. I'm already looking for a 100% pure Java open source relational database that enforces referential integrity, and I'd welcome any suggestions of where to find one. It's far enough along I really don't want to start over. But, if I did, I could change the database and integrate Hubby's HTML JTextArea component from the start. Tough call, and I don't want to decide.