Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I have been asked to work in a Java web application that is very very poorly designed. In the name of "making this easy", they have come up with their own "framework" to make things extremely difficult to understand. I am struggling to figure out the control flow. Do you have any such experience?
What do you do in such situations when the guy who has "designed" it has already left the company?
While trying to figure out how this works, it's probably a good idea to write unit-tests for it. That way you know what happens when a parameter enters and in the future you still know you haven't broken it. Perhaps even refactor it a bit so you can use Dependency Injection so the unit tests can remain small. This probably isn't easy, so first try to write some scenario-unit-tests and make them smaller while you progress. This way you can make sure the application remains stable and you learn a bit out of it.
If you got time, I'd suggest reading this book a bit Working Effectively with Legacy Code. It has really nice pointers on how to act in such a situation.
In my short 3 years career I had 3 products to maintain in such condition. And form me there is 3 periods in my mind:
At first you should read line by line and try to figure out, how code works, personally I draw maps on paper. After couple weeks of this you can almost easy do changes and do not much harm for rest of a code. Latter refactor bit by bit, and you could change everything knowing you don't harm any yours and previews code.
Do you have any such experience ?
Yes. I almost said "of course".
What do you do in such situations when the guy who has "designed" it has already left the company ?
You deal with it. It is part of your job. How you deal with depends on what the application is, and how bad the problem is, but it ranges from:
Depending on the nature / extent of the problem, you may need to bring it to management's attention. But you may have to deal with the issue of convincing management that the problem is in the code ... not in your ability.
And remember that the corporate world is full of crufty old code-bases that are too hard / too expensive to fix or replace. The typical management viewpoint is typically that something that works (just) well enough doesn't need fixing.
I've the exact same feeling whenever I have to use Struts and most other "frameworks"...
Get used to it, most if not all software is poorly designed. The more design went into it, the more likely its design is to be poor (as exemplified by the worst designed application I ever worked with, which was massively overdesigned by someone who had written books about software design and applied every single one of them to that system at the same time).
Do you have any such experience ?
I have almost exclusively such experiences :-) Most of the projects I have worked on were legacy projects. It is difficult to understand someone else's code, especially if it has a long history of changes. It may originally have had a nice and clean architecture, but without constant care and refactoring, any design will inevitably rot over time.
I have answered a similar question on SO a while ago, before PSE came into existence. Hope it helps you too.
Although that question (and my answer) would now fit better here, I though it better to avoid duplication, so I just link to it rather than copying the text.
It's a tough spot. You can try to find anyone in the organization that has any experience with the application at all. Short of that, you're just going to have to bite the bullet and start reading the code and stepping through the debugger as you trace your way through some use cases. Start with simple ones, then work your way from there.
A good and simple way to learn about the control flow is to hook up a profiler. Go into the app, start CPU profiling and then execute the action you want to know about. When this has finished, stop CPU profiling and have a look at the generated call graph. This will give you the complete path from front end (UI) pages and actions to biz logic in the server up to the sql statements going to the DB.
Unfortunately, you're going to suffer more with this current position than the code-hopefully not. Some had a great idea initially that they would build this great framework and the rest of the code would just fall into place. Then reality sets in. Right in the middle of the framework project someone wants to see more of a working site so they can demo to investors, sr. management, business partners, or some VIP. So they have to stop what they're doing and put something together. Just when they thought they were back on track, someone needs a change to the old application because of some regulation, law, or a typical business whim.
Eventually, someone expects this project to be on time or since the demo went so well, you should be ahead of schedule. Never mind that the accounting department had to delay their testing for two weeks (Didn't anyone mention end of quarter?).
Now you show up. They expect you to pick up where your predecessor left off. You're constantly fighting the desire to start all over again instead of learning the Framework to the Matrix. You'll find out it is not so complicated as long as your class names are palindromes.
Fix this mess. Be the unsung hero and wait for the next project so you can write your own framework.
I think almost every developers meet such situations.
The point is "poorly designed" can run, even it works fine online.
Conservative strategy is: refactoring it by small step by step, it's safe for you and your code:)
