Anyway, I'm changing a lot of stuff. The application I'm working on is a tangled mess of non-thread-safe, non communicative code that was written a few years back by some people who were very pressed for time and, to be honest, not very good at java programming. But hey, it's been working fine for a few years now and the reason we're rewriting some parts is to show our client that spending money on maintaining code is a good thing.
Right now I'm focusing on breaking up the application into separate layers. I'm bringing in tons of new classes that will be useful throughout the application. The previous model focused mostly on use cases and the objects used for use case A were not reused in use case B, so there is quite a lot of duplicate code in there but because the code is so non communicative it's difficult to see the duplicate parts.
Since the application wasn't really layered to begin with there are tons of places with tightly coupled code. I'm taking the sledge hammer approach to this and just smashing those couplings. Why should the class that's responsible for retrieving data need to know stuff about html forms? And why is the html code for producing drop down menus hidden way back in a utitily function of a servlet? And why are there so many scriplet tags in the JSPs? I'm busy writing taglibs now..
My time estimate for doing this job is way off. I've probably underestimated it by 50% or so. But I think that's mostly due to me having to rewrite more than I expected at first because of all the intricate dependencies. Once they are gone I think we'll be back on track again and even if I'd missed by 200% it would still be worth the effort. Once this job is done we'll have a good solid foundation to build general purpose functions on and we can start to replace all the use case based functionality.
My friends through this journey are:
- The Spring framework - thanks for those jdbc templates and the error handling!
- Atomikos - thanks for the XA!
0 comments:
Post a Comment