I recall a while back seeing an experimental code visualization tool, with the intention being to enable a user to manually track interconnectivity between different parts of their code for the purposes of implementing specific features. In particular, a user could pull out a window into their code and associate it with a completely different part of their code, seeing lots of independently controllable code snippets (and any relevant notes) linked together. The purpose of this tool was to enable someone working on a chunk of code that crossed multiple functions (or separate modules) to be able to more cleanly figure out what was going on and to see more of the relevant code at once. This is kind of similar to just opening boatloads of small windows at once, drawing lines between them, and having each window be a view of a file (some windows could be looking at different parts of the same file, some windows might just be notes).
I think the experimenters made an Eclipse plugin for the concept using Java.
Anyone have any idea what I'm talking about?
Maybe CodeBubble?
The essential goal of this project is to make it easier for developers to see many fragments of code (or other information) at once without having to navigate back and forth.
Each of these fragments is shown in a bubble.
(although Mylyn is kind of similar in its approach, but with less diagrams ;) )
Related
I have a bloated JDialog class (~2000 lines) that displays two unrelated JTables. I want to split it into three classes (JDialog, Jtable1 and JTable2). I can study which variables and which methods are used by each table and move them to relevant classes, but this manual refactoring is going to be tedious.
Is there any way to automate such refactoring?
To achieve this a script should have an accumulator of tokens. First token is, for instance jTable2 from panel.add(jTable2). Now check all lines that have jTable2 in them and add tokens to accumulator. Repeat search for relevant tokens until new tokens are not discovered. Now for each token find lines that contain it. Expand selection to include brackets.
It is hard to believe that programmers of the arguably largest language haven't created such a tool yet. This should be pretty similar to find usages tool in IDE.
Automatic? No, thank goodness. Refactoring requires thought. Deep learning isn't there yet.
Most IDEs (e.g. IntelliJ from JetBrains, the best IDE on the market) has excellent refactoring support.
But it won't think for you.
One piece of advice: You'll have better luck if you have unit tests, do it in small incremental bites, and use a version control system. Write a test, make a change, show that the test still passes, commit the change, repeat.
You can always go back to the last working version that way. You won't make a bigger mess than a single incremental step.
I think you can do even better: look at moving listeners and processing code out of the UI, too. Swing apps end up with big classes because people learn to cram everything into the UI classes. If you decompose it you'll find that the code is easier to read, more modular, and easier to unit test.
In NetBeans you can use Refactor->move. It starts a wizard that conveniently displays relevant methods. You need to select them that you want to move, but you don't have to hunt in code. Other IDEs have similar functionality.
This way you still have to think, but the boring part of finding them is done for you by IDE.
Take a look at this post (How to refactor thousands of lines of Java code? Is there any tool available?) that asks a similar question.
Basically, there are some production quality tools that help you extract classes once you know what it is what you want to put in the classes. Notably, IntelliJ's IDEA has a good "extract class" refactoring.
The harder part is determining what should go into those classes. AFAIK, there are only research tools available for that.
MS Visual Studio's autocompletion is called intellisense and the code completion doesn't list the possible functions etc in alphebetical order. It looks at the code around where you are typing and puts the most likely function etc at the top. For instance, if you have called a function named "Draw" multiple times previously, it will move "Draw" up in the list. Eclipse code completion just lists the functions etc in alphebetical order. The attached image shows what I mean. Is there any way of getting the code completion to act like Intellisense?
You can try to install Eclipse Recommenders Plugin. It uses information collected from other developers and tries to provide you most relevant completion.
Code Recommenders automatically analyzes existing code using that API and extracts common usage rules and patterns from it. In the form of recommendation models, this knowledge is then fed back into your IDE. Code Recommenders’ intelligent code completion and extended API documentation then utilizes the power of these models to provide you with the solutions implemented by other developers in the past.
I am working on my bachelor thesis (this is my first research project) and trying to evaluate different possibilites to monitor a developers work during a day, aggregate it and illustrate it later. For this purpose, I defined some metrics, I want to measure (they might change over time and there might come more).
My questions are related to the monitors. To start, I have decided to monitor the developers work (only) within Eclipse (and add a TFS implementation later):
Work Items: I want to know how many work items the developer solved, edited and created. If possible, I want to access the data from MyLin, because multiple different task/bug-trackers can be used (Bugzilla, Mantis, etc.). Unfortunately, I am not sure, if this is possible somehow?
IDE-stuff: (To start), I want to count the number of selects and edits in the code and probably also the number of clicks a developer made within the IDE. I read, that I can create listeners on Eclipse and get the data. Is this right and does anyone know a nice tutorial on that topic?
Source Code Management: To track a developers work, I need to get the developers source code changes (commits). For SVN, GIT and CVS, there are multiple APIs, which I may access with Java or also via webrequests. But before I start that, I wanted to ask you, if someone knows a plug-in or something where I can access the commits from different version control systems? What is the easiest way to do something like that?
I also have a couple of other things, I am going to measure... My aim is to aggregate the data within an Eclipse plugin and then send it the server for the visualisation.
I am not necessarily looking for fully implemented solutions, but more for hints, tutorials, tips, your opinions and probably also questions and propositions!
thank you!
You can try out with rabbit plugins for eclipse to track the time spent on it. It has different trackers to record the statistics about different commands executed, duration of the perspective or views used, time spent on editors etc.. And this plugins has a view to see all the statistics collected. have a look at the following link:
http://code.google.com/p/rabbit-eclipse/
Some of the metrics you want are produced by Hudson/Jenkins plugins as a starting point you could look at how those plugins produce those metrics. Same applies for the Eclipse metrics find existing plugins which manipulate or consume some of the metrics you want and use that as a starting point - since most of them are OpenSource.
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'm starting a fairly complex Swing application that heavily graphics-oriented with about 1000 separate jpegs, 30+ different forms, and timers keeping track of the rate of user-interactions throughout.
My question is from a practical programming perspective, after I've already written a storyboard for the entire project and got it approved by the client, where's the best place (code-wise) to begin programming this massive project and in what order should I program the elements?
(Example Answer: first begin coding the declare and init statements of all the necessary pieces, then write skeleton versions of all the methods, then deal with swing design and layout manager (gridbag), and then deal with Events and Listeners)
Thanks for the advice everyone, oh and btw I really love StackOverflow!
You're describing a "waterfall" development approach - completing some level of the program first, then completing the next level etc. It's indeed one possible approach, but many people find it so called tracer bullet approach better; first make something functional, then learn from it, adjust what's needed and proceed. It's especially useful if you're working with a client, because by showing prototypes you can get feedback and avoid misunderstandings.
I'd pick up a book on TDD and even if you're not going to write automated tests, it will be full of good advice on how to approach your project.
After that I'd pick a single piece of functionality that slices all the way through your application vertically and implement that end-to-end. This should allow you to get any infrastructure/frameworks in place and spot any gotcha's that may get thrown up out of your design.
If your client has the time free, show them each piece of functionality along the way and make sure that every piece you do adds some value to the product.
--EDIT
In addition I'd take a look at using a graphical designer for your screens instead of using the GridBagLayout. That will just waste time and can quickly become a maintainence nightmare when changing screens. I personally prefer the ones that work in a resource file type way, where the screen is essentially "compiled" and you just load it into your code
I prefer writing the UI so, that first I write (using TDD) the backend classes which implement the behaviour of the UI, without any dependencies to the presentation of the UI (i.e. without Swing or any other UI library). After that I write a thin presentation layer with an UI library, where all the event handlers etc. delegate to the UI backend (they should be just one-liners without any logic). The benefit of this is that you can easily write tests for the UI, which in turn makes it easier to change and maintain the UI. See the links at http://martinfowler.com/eaaDev/ModelViewPresenter.html for more details.
At a higher level, first implement the features which will produce the most value to the users. Try to get something to show as early as possible, so that you can get feedback from the users and improve any deficiencies in the UI. You can fake most of the background services (for example the database and business rules), so that the UI can be used, even though it does not yet really do anything.
I think mad-j has the words of wisdom.
Don't concentrate on the 'all'... identify sections/components/modules and deliver those. Then move on to the next and the next. This is called Iterative and Incremental Development (a response to the weaknesses of the waterfall model)!
This will also allow you to create tools and frameworks which should make your development easier and faster as you move along.
This will allow you to show your clients functional parts early. But a word of advice! Your client will more than likely keep changing its requirements, changing the GUI, changing its mind, etc. I've seen entire projects fail due to these continuous changes. It is out of the scope of this question to mention any more on this, but please be aware that it more than likely will happen and be prepared to deal with it!
If you and the client have functional parts, they can be tested immediately rather than testing one huge system.
By completing functional parts iteratively will probably allow you to work at every layer, on most API's using most tools and technologies. The advantage of this is that it will allow you to identify the complexities early. It is those complex areas that render this following statement true:
The first 90% of the code accounts for
the first 90% of the development time.
The remaining 10% of the code accounts
for the other 90% of the development
time. --Tom Cargil
Identifying, acknowledging and understanding those complex areas will allow you to manage your risks and alter your efforts and resources more effectively.
Good Luck,
Jeach!
As mentioned by MrWiggles, you may want to look into using a UI builder.
If you're looking at writing many forms, and it looks like the form data can match nicely to some javabeans, you may want to think about creating some framework panels first.
If you can create some simple base classes that take care of the wiring (syncing the fields to the beans and vice-versa), it'll save you a lot of work.
You may even want to set up some panels that will "auto create" fields based on beans. Just pass in a bean and the panel creates itself. The trick there is specifying layout for the fields, and dealing with fields that have fixed values, validation, etc. (Fixed values can be dealt with using javabean property editors - see http://javadude.com/articles/propedit/index.html.
If you're set on using Swing (eclipse RCP is nice, btw), you might want to look at the Swing Application Framework (https://appframework.dev.java.net/). If not using it directly, it may give you some ideas on how to set up bindings.
Hope this helps a bit
Are you really sure of Swing? Eclipse RCP is much better and flexible starting from EMF and going on
Anyway with Swing, first I'll prepare an XSLT template of all: common code routine and other common pieces of common to bring then them in abstract and interface classes, ORM patterns you use.
Then I'll design a common UI scheme, this "xslize" too.
After all with ANT XSLT processor I'll prepare a complete build procedure upon your specs.
P.S.
I made similar projects for simple web and swing cruds just before 2001, and if you use some peculiar UI designer you can also nest or write with xslt every specs without putting dirty code in your ui raw concepts, so when I make/add remove features on all or singular piece of code, 30 seconds maximum for full rebuild of ALL, of course you must "XSLIZE" all using also many xslt overrider/import.