I have done some Java programs on my own but now I found an interesting Java project to work. I chose one item from todo list and now I would like to implement it and find a suitable place in the original code for it. What are some good strategies to find the correct place? I'm using Eclipse Helios and its debugger.
This is where coding convention and technical documentation would help you. If the java programs you are talking about is written correctly with the correct conventions and everything, you should be able to figure out where your code should reside.
Best way would be to run through the part where the TODO is needed. If the todo is specific to current class, it would be ideal to just put it in the same file. Of course, TODO usually (but not all the time) means that it might be an enhancement to the current code. If that's the case, then creating a new method for it would be good.
if on the other hand, you think your code would be useful for the entire project, a utility method would be the perfect place to store your code.
If it's something you can make a local copy of, try getting it all to work IE do a couple of test runs, and then try deleting some files that look unimportant. It may sound silly but it'll show you straight away whether or not something is a core part of the code.
Once you get down to class level, read the whole thing. Eventually you'll get to know a few core classes really well and gain a basic understanding of what all the others do.
If you are completely new to a project, but that project has other developers I suggest you ask someone more familiar with the code base. If you are on your own you would have to see if there are any functions that are similar to what you want to do. You could then try and put your own code in the same place (package/class/whatever is appropriate) and job done!
Good luck!
Start working on a private branch (you do use some version control software, right?) and make sure you understand how to validate the project (you do use automated tests, right?). After that, just start experimenting!
If this is an open source project then it most likely have some means of contacting the developers for the project. A mailing list is usually available, where you can ask these questions to those who know the code well.
Remember to choose an active project...
Related
I'd like to try using WebTest, preferably from Clojure, but I can only find its functionality exposed as Ant tasks. There seems to be some sort of Groovy interface, which implies that it's possible to use from any JVM language outside of Ant, but I can't figure it out.
I'm hoping to use WebTest as a "scriptable browser" to load up someone else's page and see if it does various unpleasant things, rather than test my own page with every build, so Ant doesn't really seem like an appropriate solution if I can avoid it.
It is often the case that useful Java functionality is hidden behind Ant tasks. I hit the issue when writing the book (pre-leiningen et al), and wrote lancet to let you call Ant tasks as clojure functions.
Lancet would probably need to be extended to handle arbitrary Ant tasks, but since it is now being maintained (as a dependency of leiningen) you might find other people willing to help out.
I am late into the game.
What about directly using the underlying httpunit java library straight from clojure ?
I am a novice programmer and as a part of my project I have to modify a open source tool (written in java) which has hundreds of classes. I have to modify a significant part of it to suit the needs of the project. I have been struggling with it for the last one month trying to read code, trying to find out the functionalities of each class and trying to figure out the pipeline from start to end.
80% of the classes have incomplete/missing documentation. The remaining 20% are those that form the general purpose API for the tool.
One month of code reading has just helped me understand the basic architecture. But I have not been able to figure out the exact changes I need to make for my project. One time, I started modifying a part of the code and soon made so many changes that I could no longer remember.
A friend suggested that I try to write down the class hierarchy. Is there a better(standard?) way to do this?
check in the code in some source code repository (Subversion, CVS, Git, Mercurial...)
make sure that you can build the project from the source and run it
if you already have an application that uses this open source tool try removing the binary dependency and introduce project dependency in eclipse or any other IDE. run your code and step through the code that you want to understand
after every small change commit
if you have different ideas branch the code
There's a great book called Working Effectively with Legacy Code, by Michael Feathers. There's a shorter article version here.
One of his points is that the best thing you can do is write unit tests for the existing code. This helps you understand where the entry points are and how the code should work. Then it lets you refactor it without worrying that you're going to break it.
From the article linked, the summary of his strategy:
1. Identify change points
2. Find an inflection point
3. Cover the inflection point
a. Break external dependencies
b. Break internal dependencies
c. Write tests
4. Make changes
5. Refactor the covered code.
Two things that Eclipse (and other IDEs as well) offer to 'fight' this. I've used them on very large projects:
Call hierarchy - right-click a method and choose "call hierarchy", or use CTRL + ALT + H. This gives you all methods that call the selected method, with option to check further down the tree. This feature is really very useful.
Type hierarchy - see the inheritance hierarchy of classes. In eclipse it's F4 or CTRL + T.
Also:
find a way to make so that changes take effect on-save, and you don't have to redeploy
use a debugger - run in debug mode, within the IDE, so that you see how the flow proceeds
My friend, you are in deep doodoo. Modifying large, badly documented legacy code is one of those projects that makes experienced programmers seriously contemplate the joys of selling insurance, or some other alternative career. However it isn't impossible, and here are some tips that I hope will help.
Your first task is to understand the code as much as possible. You are at least on the right track there. Getting a good idea of the class structure is absolutely important, and a diagram is probably the best way. The other thing I would suggest is that when you find out what a class does, add the missing documentation yourself. That way when you come back to it you wont' have forgotten what you found out.
Don't forget the debugger. If you want to find out what is really going on, stepping through the relevant code, or simply finding out what a call stack really looks like at a certain point can be very helpful.
The only way to understand code is to read it. Keep working that is my advice.
There are projects with better documentation than others. Here is a couple of projects that I know are well organized:
Tomcat ,
Jetty,
Hudson,
You should check java-source for more open source projects.
Personally I think it is very difficult to try to understand an entire application all at once. Instead, try to focus only on certain modules. For example, if you can identify a module that you need to change (e.g. based on a screen, or certain input/output point), then start by making one small change and testing it. Go from there, making a small change, testing, and moving on.
Additionally, if your project has unit tests (consider yourself lucky) and review the unit tests of the module you are focusing on. That will help you get an idea of what the module is expected to do.
In my opinion there is no standard approach to understand a project. It depends on many factors, from the understandability of the code/architecture you're analyzing to your previous experience on large projects.
I suggest you to reverse-engineer the code by using a modeling tool, so that you can generate some UML models from the existing source code. These diagrams can be helpful as a graphic guideline during your anaysis of the code.
Don't be afraid to use debugging to grab the logic of the most complex functionalities of the project. Running the most complex code instruction by instruction, seeing the exact values of the variables and the interactions between the objects can be helpful.
Before you refactor to change the project to suit your needs, be sure to write some test cases, so that you can verify that your modifications don't break the code in unexpected ways.
Here are a couple recommendations
Get the code into some form of CVS.
This way if you start making changes
you can always look back at previous
versions.
Take the time to document what you
have already learned/gone through. Javadoc is fine
for this.
Create a UML structure for you code.
There are lots of plugins out there and wil give you a nice representation of your code layout.
I have just created a mid-sized web-application using Java, a custom MVC framework, javascript. My code will be reviewed before it's put in the productions servers (internal use).
The primary objective of building this app was to solve a small problem for internal use and understand the custom made MVC framework used by my employer. So, my app has gone through MANY iterations, feature changes and additions.
So, bottom line, the code is very very dirty and this is my first "product level" Java app.
What are your suggestions, what are some basic checks/refractoring I should do before the code review?
I am thinking about:
Java best practices (conventions)
Make the code simple to understand for the developer who will maintain it. (won't be me)
I noticed, I have created some unnecessary objects and used hashmaps/arraylists where could have easily used some other Data structure and achieved the solution. So, is that worth changing?
Update
Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews
If you did not already, (assuming you use an IDE like eclipse)
get plugins checkstyle and findbugs
go through their configuration and tune to your style
run them on your code
resolve all issues reported
you can also tune the compiler warning setting of eclipse itself and possibly make them more strict in what is reported.
Look at code structure:
get plugin jdepend
investigate your package structure
Code against interfaces (Map, List, Set) instead of implementation classes (HashMap, ArrayList, TreeSet)
Complete your Javadoc and make check it is up to date after all refactorings.
Add JUnit tests; if you have no time left to test the whole application, at least create a test for every bug you find and solve from now on. This helps "growing" a test set as you go.
Next time design and build your application with the end goal in sight. Always assume that the next guy having to maintain your code will know how to find you :-)
Unit tests, and they should be automated as part of your build. You should already have these, but if not, do it now. It will definitely make the refactoring easier, as well improving your general confidence in the code (and the guy who will be maintaining it).
Logging.
One of the more overlooked things is the importance of logging. You need to have a decent logging methodology put in place. Even though this is an internal app, make sure that the basic logs can help regular users find issues and provide more detailed logging so that you (the developer) would know where to go.
Comment your code, explain why it's doing what it's doing and what assumptions have been made.
Try to reduce the amount of mutating state.
Try to remove any singletons you may have.
There are few open source projects/APIs/libraries that we use in our project (Spring, Struts, iBatis etc.) and I want to understand their design and how they work internally.
What is the best way to understand these projects? Note that I am already using these libraries in my project. And I know the input-output interaction/configurations for these libraries. What I don't understand is how these APIs/libraries work internally.
The problems I face is:
Finding the entry class of the library. Is there any way I can know the entry class for the library - something which is kicking the whole API?
Tools/Plugins to use in Eclipse to get an overview of the design of the library. Going through each and every class of the library, can be a very daunting task. Is there any tool you would like to recommend which can generate the class diagrams of the API in Eclipse.
Thanks in advance!!
UPDATE: I need some inputs on eclipse plugins which can help me in getting an overview/class diagram of the library
I always use the same strategy for this: I never try to "understand" the code base as a whole, and I usually try to follow the request flow. I read enough of the documentation to determine what is necessary to use the application, and I read that code (Keep all source code loaded in your IDE).
For example, in struts you'll be installing a servlet filter in web.xml. Start reading the filter and follow the path a single request takes through your stack.
Likewise for spring, there are two main entry points, the filter and "getBean", both of which are mentioned real early in the documentation. Read those two.
For both of these cases you'll find one or two classes that represent the "core" of the framework real quickly. Read those really well and let actual use cases & needs drive your further exploration.
Approaching "understanding" of an open source library (or any other code base for that matter) by trying to find all the pieces is usually not a very good way of approaching these things, it will usually just lead nowhere because a lot of these things contain too much code. When following the request flow I find making diagrams can also be quite distracting, it tends to draw attention/focus away from understanding (and since my understanding increases rapidly most of them are out-of-date even before they reach the printer).
Nice question!!!, what I've done, specially in the case of Spring, apart from consulting the Documentation and their API's is to attach the sources of the project to my project on Eclipse, that way I'm able to navigate through the source code, not just the API. Its been quite helpful specially in the case of the Spring-Security project, there were some concepts that I just couldn't understand until I inspected the source code.
That's one of the advantages of using Open Source libraries.
Regards.
Tools like Structure101 (http://www.headwaysoftware.com/products/structure101/index.php), and Lattix (http://www.lattix.com/) let you analyze code and produce architecture diagrams / dependency matrices.
This is not exactly class diagram - the main focus is on layering. So the entry point is usually the topmost layer.
But then again, as I specified above, you will notice that some libs are just a mess, and these tools will not be helpful enough.
See the S101 online demo: http://www.structure101.com/java/
This for example is the Sonar project architecture: http://www.structure101.com/java/tracker/sonar/1.11.1/arch.html
Your best bet for those three would be to consult the official documentation (make sure you are looking at the version you are using) or to get a book on the technology.
Most APIs don't have a class with a main method; they're running in the webserver called by the server itself. Unless they're running as their own server, they won't have a main method.
This seems to be a popular complaint on many programmer forums so I wouldn't be surprised if this question was already on here. Sorry if it has already been answered but I've searched and couldn't find one that relates to Java/OO.
I have a somewhat complicated application that was written a number of months ago. It works well, but is slow and the code is extremely ugly. Classes are split up for no logical reason, half the UI is in the logic code and it's really frustratingly built. I want to redesign and redevelop this program to the correct design standards, yet I don't want to break it completely. There's no design documents, no documentation, nothing but the code (with no formatting) and the built application.
What's the best way of taking an existing Java project, written in the most annoying way possible and redeveloping it in the best way possible? Are there any good tools that'll help me find speed bottlenecks or for extensive testing in NetBeans? Any help for a total novice of testing would be greatly appreciated.
EDIT: You're correct when saying that we don't really understand this program. It does what we want, but it also does other things and we're not exactly aware of, like creating strange graphics and weird numbers appearing on the UI. The main reason we want this redesigned is so that we can actually find out what's going on, but as I've said the code is so messy you'd think it was written by a genius that didn't want us to find out his secrets.
"with no formatting"
Netbeans has an automatic formatter option in the "Source" menu. That would be a good start.
"There's no design documents, no documentation, nothing but the code"
As you work out what parts do, it will serve you well (and your successors) to document this. That way you will start having documentation you can refer to.
Using JUnit to start adding some Unit Tests to sections before you refactor them wouldn't hurt either.
"I want to redesign and redevelop this program to the correct design standards, yet I don't want to break it completely."
Start small. Work out some simple things that could be designed better and concentrate on them first. Using the Refactor ability in Netbeans will help greatly with this. Concentrate on making sure everything that you refactor still works the same (which is why starting out small helps). The more of the small stuff that you clean up, the easier the bigger stuff will be when you come to it.
Also, make sure what you are refactoring is actually an improvement...
I would echo C. Ross's comments and add these strategies for common "bad code" scenarios I've dealt with in the past:
Code Duplication: The only thing worse than bad code is multiple copies of the same bad code. Get familiar with the entire code base by speed reading it (get it's flavour) and identify instances of cutting-and-pasting code. Refactor those to a single implementation and remove the duplication. That may be it - or you can continue to refine the single copy of that code.
Don't be in a hurry to fix it: Only clean up code that you actively need to maintain and/or understand. This is a variation of if it ain't broke don't fix it I like to call if you don't need to change it don't fix it. But, anytime you need to touch a piece of code take 10 extra minutes to clean it up. Maybe that's just adding formatting it, adding some inline comments, renaming variables to make sense, etc. Any code you need to update will most likely be revisted again in the future, and now you've made it all clean. Code you haven't had to actually change yet can remain ugly without harming anything.
Good luck :)
As already mentioned, an ugly code can be cleaned up by a monkey with a proper IDE so I wouldn't go to your manager with that argument alone.
Being pragmatic, I would go with:
grab some tools (a profiler, code duplication tools) to find a couple of pain points
for each point, come up with a battle plan how to solve it (with short specification, design, maybe code sample, test cases...).
go to your manager and let him decide which one to tackle first
The danger is to do too much and to try to clean everything. Depending on the size of the application, it may take years to clean it up (because you won't do this full time) so just be patient.
And of course, when you revisit part of the code, just clean it up with your favorite IDE.
Really the only answer is sweat equity, but some things that can help:
A good IDE with refactoring tools, such as Eclipse
Profiling tools for optimization
Code coverage tools, such as EclEmma
Javadoc, sometimes it helps to get a high level view of even bad code
Happy refactoring!
What you have is essentially a prototype. Tell your manager that that is what it is, and that it should be rewritten to reach production quality.
JProfiler is excellent, I was using it just yesterday in fact to find a performance bottleneck in some Java code I had.
If you can get some automated tests in place you'll be in a better position to start refactorring as you can then assetr that it's still functioning as expected. Specifically you should focus I think on very high level tests of the system, if it's a web app take a look at selenium and/or other web app testing frameworks.
Apart from that, be ready to head down a lot of dead ends, try and avoid taking too much change on at once if possible. The more you can break down the largre app into smaller chunks which you can take on one at a time the more succesful you're likely to be. Also, be prepared to accept that some of it may well remain crappy forever, if it ain't broke as they say, don't fix it.