Monday, January 21, 2008

Refactor Groovy code?

I love Groovy! It's great for getting things done quickly. From Groovy, I can call Ant and XSLT easily. I can build and parse XML. I can call external applications, read file content and traverse a file hierarchy with very little code. And I can modify my program at runtime, without compiling and deploying it again.

But this dynamics come at a cost. For instance, I really miss code completion. Some times, I go to a Java editor and create an object of some class and push CTRL-SPACE to find out the parameters for a method. Also, I miss that the editor doesn't indicate errors if I misspell a function or variable name.

And I always wondered how well a dynamic language would scale. Now, I think I know the answer: It doesn't scale well! I have a Groovy template of 500 lines, and it's almost impossible to modify it. And today, I have been trying to refactor a Groovy class of 800 lines, and it's really, really hard.

How hard would it be to modify a Java class of 500-800 lines? Not hard at all. Unfortunately, the Java version of these classes would probably be several thousand lines long, so there is no perfect solution that I know of. And I can probably blame myself for hacking these unmaintainable scripts together. But that's why I loved Groovy in the first place! The ability to produce something quickly.

Actually, I write some code quickly in Java too some times, but I never have any problems refactoring it later. Maybe the problem is that there is no refactoring support in Groovy. I am so spoiled by Eclipse for Java in this area. I really hope this is the problem, and that refactoring support and auto completion comes to my editor soon. Because I love the productivity that Groovy gives.

Until then, my advice is this: Use Groovy for relatively small scripts or to replace several other tools with one. For larger programs, I think it's better to stick with Java for now. Unless you know the domain, so you write code right the first time, and never need to refactor it.


Andres Almiray said...

Refactoring is not something the language provides by itself but the tools do. Because dynamic languages give you more freedom is a harder task to make the tools but not impossible. The tools are coming, in fact, they are already here, I use Eclipse & Groovy *every single day* and so far refactoring has not been an issue. The folks that use IDEA say that JetGroovy has better refactoring options among other things.

Now if a Groovy class is more than 500 lines long then probably there is something very wrong in terms of design or impl since the very beginning. Groovy code is inherently smaller than its Java counterpart in almost all cases.

Lars said...

Something wrong with my code??? No way! And if it is, it's Groovy's fault, since it makes it so easy to get something running quickly, it has made a hacker out of me. Just kidding. In fact, it's maybe the excellent Java refactoring that has given me bad habits.

I certainly agree that it's not the language's fault, it's the tools that are not ready. I don't think you can say that a class with > 500 lines is always wrong. But if I made such a class in Java, I would have no problem dividing it in separate classes later. But that's much harder in Groovy.

So, in Groovy, I have to make right classes from the beginning, I cannot "design" (refactor) it afterwards, as XP is proposing.