Understanding a reasonably large Java Web App Codebase

Question

While interviewing for a company, I pair programmed with someone who showed me the large codebase for the product I will need to get familiar with. Here are some of the characteristics of the project:

1. Uses Spring Framework for business logic (3.2), which uses JPA for the data access layer. MySQL on the backend with Hibernate and they also use Project Lombok.
2. There are about 100 @Entities. They use JSP pages, a mix of a few front end bits.
3. Statistics show that there are about 2000 Java classes and the code has been developed by many different users with different styles.

All in all, it's a typical, rather not consistently developed enterprise Java application.

About me: I am an experienced Java programmer, but I don't have much experience with Spring/Java. I do understand web applications well and have done quite some Rails development.

In a way, accepting this job may be a step backward. But I need this job. So, I have a very specific question. How should I approach it? How should I go about asking questions, understanding the details of it so that I become effective with doing bug fixing and feature development? I have seen this generic thread , but I want to understand the specifics (actionable items) wrt this environment (Java Web Development with Spring/JPA/Hibernate) (although the principles perhaps remain the same).

Answer 1

The answer is heavily dependent on their architecture. If they tried to keep a single thread, non-mutable simple architecture then you're golden. If they went with a heavily async event driven model, then you're life is going to be harder as those are much harder to completely reason about. As far as Spring/JPA/Hibernate, if they've done a decent job of domain modeling, then the the hibernate/jpa portion basically shouldn't really matter. That's the whole point of JPA/Hibernate, it should abstract almost all the major details away and you should deal with things like look like POJOs. If they didn't do a good job with it, then again you're going to have a lot more work. To be honest once you get the basics of Spring down, it is usually easy to reason about in a program.

Most of the spring stuff I've dealt with is usually easy to think about. Basically you look for autowired (or whatever their using to inject their beans). This tells you who is dependent on who. If you get in to Springs more complicated features (weaving, AOP, etc....). Things get harder as you have to have a very strong understanding of when Spring will actually execute the code.

The other areas that can be more complicated are the interactions between the app container and Spring. Again without knowing what exactly their using and how their using it I can't offer many details.

TL;DR; If they've designed it well, and kept unneeded complexity out of it you're fine. If they didn't you're going to be spending a large amount of time having to debug the actual flow of the program to figure it out. Never seen a short cut way out of that situation.