Even More Groovy

I have a confession to make.  My neat little code counter utility is partially a lie.  I wrote the entire thing as a single Groovy script, and only split it up into individual files for each class to release it.  271 lines of code (419 if you count the blank lines) simply does not justify seven distinct files.  That said, it does justify a runner script and six distinct classes.  So if you want the "real" source, just take the six classes, copy them directly into Runner.groovy and then delete the files.  Everything works exactly the same, except it's all in one concise package.

The project started with a pile of procedural code (i.e. a Groovy script), all inline with no classes at all.  My basic concepts proved sound, and I started refactoring.  Does anyone NOT like refactoring?  If so, raise your hand so I'll know who to slap.  ;)  Classes quickly started falling out of the proof-of-concept code, and soon I had my four core classes (CodeCounter, ProjectInfo, PathInfo, and FileInfo), plus some no-longer-quite-functioning output code.

Once the "backend" was refactored into a stable model, the front-end went just the same.  XML was the format of the original script, and so I reimplemented the same output based on the model, rather than emitting it inline.  To ensure I wasn't being stupid and coupling where I shouldn't, I threw together the text renderer as well.

I'm a huge fan of this style of development, and do much the same thing with CF.  Start writing one big-ass file with no real concern for parameterization, abstraction, or encapsulation.  Once it works "enough", start refactoring for those three characteristics, as well as extending the functionality into something useful to the real world.

Doing Java is a bit harder, since you have the object nature foisted on you from the start.  You can still begin with one class and a pile of static methods, but the refactoring is a bit harder, I think, because of the static/dynamic transition.  With CF and Groovy, you pretty much bypass all of that (thank you compilers!), which is very nice.

What's the downside to this style of development?  Unit testing is hard.  With a rapidly evolving project (structurally), having to evolve unit tests can be a significant burden.  Not to mention that you can't really unit test a single large script; you're stuck waiting until you have an class which is after most of the work is done.  So if you write unit tests at all (I didn't), they have to come late in the cycle.

The main benefit is that you don't have to think about architecture before implementing functionality.  If you know exactly what your desired functionality is, and know how you're going to approach implementing it then architecture is the "hard" part, and unit tests can help ensure your implementation matches what you expect/require.  However, that's not the case a lot of time.