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 work on enterprise Java projects that do not have a single entry point from where I can trace the flow of execution. Some of the projects have hundreds of classes, and when I'm asked to add a feature to a project, I often find myself at a loss as to where to start looking at code.
What's the best way to dive into such projects so that I can implement the feature quickly without wasting time.
Does the project have a suite of well-maintained unit tests? The unit tests are programmatic documentation for what the code does.
In addition, you need to learn enough about the architecture of the application to identify the places where you need to insert code for your new features, and more or less ignore the rest. You don't need to know the whole code base to do this; if the projects are well-architected, the functionality is already sufficiently encapsulated and decoupled that you can focus on the relevant parts. If you're lucky, the projects already follow a well-known architecture which will serve as a map for you to follow.
Code always has one or more entry points. For MVC projects, the entry point is a controller method based on an URL; the method will almost certainly access a data repository, and return a view. Start there.
Start with the middle tier( business logic layer).
That is one of the places the control comes for any user actions or trigger events if it is a non UI based application. If you are in debug mode, You can trace it to the top and bottom ( most likely data access layer).
It will take sometime but this is the efficient way to jump into undocumented projects.
If the project uses any framework ( struts-config.xml , ejb config xmls , spring config xmls) will have a defined interfaces and you can start from there as well.
There's always an entry point. For Java enterprise apps: servlets, filters, and context listeners are at the top, they normally lead into application bootstrapping e.g spring context loader, which then leads into controllers, then into entities and views. It's actually pretty straightforward, particularly if a framework such as spring, tapestry, or wicket is used. Once you know how the framework processes a request, you should be able to identify the extension points you need.
I would start with a class hierarchy. If you have one great, if not, find a tool that can reverse engineer your code and create one for you. From that you can start to see how things may be related. Once you can see how things may be related you can at least target areas instead of having a large "hodgepodge" of classes. You can target an area you can see how they are associated with each other (is this class an association of this one, is this set of classes a design pattern, etc). Attempt to add some order and structure around what you're looking at and then break down each section.
EDIT:
Here are some posts from stack overflow outlining the tools you could use in eclipse (or as standalone applications) to reverse engineer and generate a model:
"How do you eat an elephant". "One bite at a time".
This is almost impossible to extend your java project if you don't get the entry points and a clear documentation of what has been done and why.
FYI: When we deliver a project to our customers we now systematically join an UML model as well as java doc and a printed documentation. We create hundreds of views from the model displayed as class diagrams. We add plenty of comments and explain the static architecture as well as business rules and methods flow. If our customers want to take his code and give it to another company it will be easy for them to modify the existing software not only at deployment level but also at architecture level. Powerful, simple and brilliant use of dynamic UML views from a single model.
Having said that I know very few integrators interested to provide all this information because once the customer is trapped it is better not to let him go. Giving full model and dynamic UML navigation will allow customers to be independent and therefore this is not good for business revenue. I still don't understand why big banks, or telecom companies are so naive to get trapped by integrators and don't ask the full model at the project delivery ? The java code or a printed documentation is not enough. The printed documentation is usually an automatic process. It has no real value to extract information from the code in order to print it or provide a PDF.
There are ALWAYS entry-points, you just have to find them. If it's a schedule-driven batch application, there are tasks configured somewhere. If it's a web-application (using Spring) there are mappings and Controllers. If it's a web services application, there are service endpoints. If it's a Swing application, there are event handlers or somesuch. And if it's a big ol hairy command line application, there is a main() method.
Regarding "diving in quickly" - well, how long it takes to find the entry-points is really individual. If the system is written according to established patterns and you are familiar with the frameworks and the underlying business rules and processes - then you should be able to figure them out very fast indeed. If not, it may take longer. But there is no universal "trick". You accumulate experience, you learn to recognize patterns and understand how the frameworks are built up and organized and you get better.
Regarding dealing with legacy code:
Regarding flow of execution:
Regarding entry point:
