While you are holding your new 'hammer',
everything looks like a nail.
And you need to learn what the real cases are that the new tool is actually is the right one for the job.
Otherwise, you end up writing lots of bad code trying to shoehorn an inappropriate method into a place it does not belong.
For me, there is a second problem that I sometimes have trouble overcoming. And that is when I already have a solution (possibly a very ugly one) that should have used this new method that I just learned. In this case, it is scary to break something that works just to do it the 'right' way.
There have been some resounding successes for me recently.
Trading JDBC data access for JPA - Amazing improvement in code understandability and speed.
Trading 'thick' servlets that included large chunks of functionality that really belonged in EJBs for EJBs - Tremendous increase in code resuse and automatic transaction support inherited from the EJB container.
Not every experiment panned out though. I used a message driven bean to perform a cleanup process asynchronously that really needed to stay synchronous (I still haven't cleaned all of the mess up from that).
So, now - as I try to learn Scala and Groovy (I can't seem to limit myself to one language at a time) it is hard to find when and how to apply them.
Oh well.
If it was easy...
Everyone would do it.
No comments:
Post a Comment