• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1211
  • Last Modified:

How to understand new java web application

Let us say main java program is in xyz.class(in package test1) which has A() method which has C() method inside that.

public void A() { C() ; }

but C() method is in different class say abc.class in different package say test2.

I keep changing to new projects every 3-6 months due to nature of my job.
If i go to new project to understand the java application esp. if one class is in service layer other classs is DAO layer etc it adds more complexity to remember.

Let us say if there are UI files(login.jsp. order.jsp, confirmation.jsp of shopping cart) from which we are doing some CRUD operation on the database with UI, SErvice, DAO etc layers is it is good idea to take paper and pen and write the flow from which package ,class, method, line which other package ,class, method, line getting called or put debug points on specific lines. Challenge is when code changes by other deveopers line numbers keep changing also.

How to understand and document the flow so that i remember al the time with quick glance wthout spending too much time.

I tried each step as screenshot and paste in word document and refer that and also take hard copy of printout. But some times that documet coming too long like 50-100 pages which is bit challenge.


please advise
Any links resources ideas highly appreciated. Thanks in advance
0
gudii9
Asked:
gudii9
  • 4
  • 3
1 Solution
 
dpearsonCommented:
If you're dealing with an application that has multiple layers (e.g. a UI layer and a database layer) then I'd suggest using a combination of 2 different strategies.

First approach is to examine the code within a single layer.  When there is a call to a new layer, ignore it for now and try to infer what the classes and methods in the new layer will be doing from just the names and parameters to the methods.

E.g.

public void A() {
    int param1 = B() ;
    int param2 = C() ;
    DAO object = createDAOObject(param1, param2, ...) ;
    object.storeInDatabase() ;
}

If B and C are in the same layer/package as A then examine then as you are reading through A.

But if createDAOObject() and storeInDatabase() are in a different layer, then ignore them for now and assume they are doing what they say (in this case saving to the database).

Once you have a good understanding for what method A() does in the current layer, then you can come back to understanding what the next layer does.

This breaks the problem down into more manageable pieces.  But in the end, a project with a large code base will always be hard to understand unless the boundaries between the components are clearly defined and easy to understand.  That's part of the skill in designing a big project.

As to how to record this - I've never seen a good way to represent it as a set of images or text.  People have tried (e.g. flowcharts were designed to show just this) but they are almost always too large and unmanageable.  In the end it usually has to just live in your head.

Hope that helps,

Doug
0
 
gudii9Author Commented:
Adding to complexity some methods come from classes of jar files which do not open in eclipse. How to take them also into consideration?
0
 
dpearsonCommented:
Treat external JAR files the same way that you treat code from another layer.

Don't try to follow the code into those files (which for an external JAR without source, is of course impossible) and instead just understand the methods as best you can from the available documentation, names and parameters.

Doug
0
Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

 
gudii9Author Commented:
Nothing to do with identifying the design patterns to understand the web application right. Otherwise that is also one other challenging task to identify different design patterns in different layers like UI, service, DAO etc. Please advise
0
 
dpearsonCommented:
Yes you generally don't need to worry about identifying design patterns when trying to understand a set of code.

You might very occasionally recognize that the code you are reading is following a specific design pattern, but design patterns are much more useful when writing code than when reading it.  They're a way to discuss and implement different designs, rather than a way to think about the code when reading it.  99.9% of the code you read will not be part of a design pattern.
0
 
gudii9Author Commented:
That makes more sense

99.9% of the code you read will not be part of a design pattern.

Above line is not clear. I thought other way. can you please elaborate?
0
 
dpearsonCommented:
Design patterns tend to be used to solve specific types of problems.  E.g. How do you write code to interface to another module - maybe I'll use the Adapter Pattern.  So the code you write to connect one interface to another could be said to be part of a design pattern, but the two sides of the connection are not.

In my experience, the vast majority of code in a system is not built to meet a specific design pattern.  It's largely code providing direct functionality - e.g. code to write to a database, code to verify input parameters in a request etc.

You learn design patterns so you have a set of tools to help solve hard problems.  But most of the code we write should not be solving hard problems - those should only come up occasionally, allowing most of what we write to be simple and easy to write.  If it all seems hard, then something is probably wrong with how you are doing it.

Doug
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now