File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Problems understanding large scale JEE applications

 
Dave McQueen
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I'm not the most experienced or skill java programmer (although am certified) so i'd be interested to have the opinions of others who are if possible?
I currently find it extremely difficult to understand large scale jEE applications. For instance, in my workplace we're given applications that we're 'reps' on, and we're expected to understand how they work. However the applications are typically, as an order of magnitude estimate, 100,000 lines of code in length, with large chunks being reused. What's more, the application in the file system is not in order of use, it's stored alphabetically according to packages then classes.
The task to digest this conceptually can be conservatively compared to taking a book the size of Lord of the Rings, cutting up all of the paragraphs, messing them up, then giving these to someone who's never read the book to sort them in the correct order and/or figure out what the plot is and who the main players are.
I'd be interested to know, why this problem exists? Is OO code supposed to simlify this? I actually find OO makes things harder to understand than procedural sometimes as for a particular use case for example, it's hard to see what method in this use case, affected my object of interest, as it's correctly been reused throughout the application. Then you have to repeat this to find the method calling the method that you've found, and so on etc.
I've been unsure about asking this question previously in case it's trivialised with a response along the lines of 'you should always be able to tell what method is calling your object in your particular use case', but I just don't find this is the case in practise. Plus with decoupling structures like Spring, Hibernate and Struts, this kind of thing can be even harder.
So enough preamble, does anyone know whether this problem is due to bad design, a lack of tools to simplify this, like something that abstracts and generalizes a code and splits up parts like a flow diagram according to use cases, or something else entirely?
Idle speculation to wildly imaginative visions of future technologies - and everything in between - are welcome!
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave McQueen wrote:as an order of magnitude estimate, 100,000 lines of code in length, with large chunks being reused.

That's very small, by the way.
The task to digest this conceptually can be conservatively compared to taking a book the size of Lord of the Rings, cutting up all of the paragraphs, messing them up, then giving these to someone who's never read the book to sort them in the correct order and/or figure out what the plot is and who the main players are.

Not true at all: there are sets of well-known entry points into JEE apps: the web.xml, framework configuration information, etc.
Plus with decoupling structures like Spring, Hibernate and Struts, this kind of thing can be even harder.

From some standpoints, yes. From others, no.

There are any number of tools, metrics, etc. you can use to help understand large-scale architecture, but the primary amongst those is the documentation that should have been generated by the architects. If you don't have that, then it becomes a matter of determining interactions, data flows, application entry points, and so on.

I write a lot of custom tools to help aid discovery, but those tools, beyond the obvious things (config files and annotations) are usually application-specific, depending on what manual investigation reveals.

I agree it's an overall problem, one which I spend a lot of time trying to understand, and automate. But there are a ton of ways to ferret out the places to start looking.
 
Dave McQueen
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David, thanks for your response - useful stuff.
I guess I'm just wondering, why isn't there a tool or application that allows you to see the java rules and data flow in some sort of flow-chart way, diagrammatically, pictorially, more abstract and general but quicker to read through, rather than having to go through code line by line, then through configuration code by line, and backwards and forwards?
It'd be great if a java application could be defined like this somehow (not sure if it can), with a series of flowcharts, perhaps at different levels, so that you could perhaps double click on a 'diamond shaped boolean section (like the parts that have 'yes' coming off one corner and 'no' off another)' and 'zoom in' on the code that's present there?
Does that even make sense? It just feels unnecessary to have to read through code when all you want to see is *where* the application can go, and not necessarily *how* it goes there (in terms of code).
A benefit would be that the business wouldn't need to understand the code and could just write flow charts, and the IT function wouldn't need to understand the business (which if my work is the norm, is pretty much a definite). They could define the business rules using a flow chart and the programmer could 'zoom in' on each flow chart section and write the code.
I'm just surprised something this obvious doesn't exist?
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic