Heart of the system, Reservation search reengineered

I’ve concluded the new search component for Base system. This has been done in fully scalable manner which aligns with most of our future technical goals. It is important for everyone to understand the concept so we can make sure the new structure would not be affected with new requirements. In order to place the new component with existing structure, several re-factoring iterations were occupied within the same set of objects.

What did I do there?
This is actually very vital question to be answered. Because to the front interface this could be nothing more than retrieving results, may be in much stable manner. But there have been lots of exercises done to ensure the application structure, transaction management, concurrency and most importantly application extensibility. It is important to have an idea about the drawbacks we faced with previous structure.

• Highly coupled front end business logic

There were bulks of logics identified inside web application tier. These business logic have to be separated and reside inside server application in order to be aligned with the meaning of a layered architecture.

• Caching mechanism is tightly coupled with the web application

We had our caching component coupled so much with the web application. This kills the reusability of that component and there were no centralized controlling or monitoring capability.

• Server was not serving properly

We have used server application just to run particular application logic only. Sever had no control or idea about the application flow, it was only managed by the front tier. For example calling thread x and thread Y runs as two different processes. Finally it’s managed by the front tier application which we should have used to process UI tier functions.

I heavily used some refactoring methods to bring this structure to level where I can start re-designing.

Refactoring legacy system...

Re-factor a legacy system is any passionate developer’s nightmare (I said re-factor NOT re-engineer). Job is really hard to go over chunk of code and try to make them in a correct order most importantly with out touching the flow of the program and with out touching the base design. As I go over it, I happen to find so much of buggy codes...not really bugs… I would say “not properly written” codes. There are number of places I can see where I need to optimize but I’m limited by the time and scope I can change over. On the other hand there is a saying “if something works don’t try to change". Sometimes I really finding it interesting to do things in different ways but other time its very boarded to move codes here and there, change variable names… etc. I work on the heart of the company base system and it really needs concentration to finalize better design.

This is kind of exercise where you get to change your wheels while you are on ride. The most difficult thing is to think through all possible issues with out practice TDD.