views:

82

answers:

3

Developers who have used eclipse cannot miss out the Cntrl+Shift+G combo - the easiest way to find all references to a particular member/method/class in your workspace. Consider a scenario where you are a new guy maintaining a web application written in java. Now, you are about to change a method signature, and you do a Cntl+Shift+G to find all references to the said method (yes, hoping that you are not doing depedency injection / reflection etc). However, a new guy, would want not to screw up any functionality in the application. How would ensure that the functional dependencies are not affected?

I guess..the question is a bit unclear.. lemme rephrase... Say you are changing something functional (an if loop in a business rule or whateva) - this will definetly CHANGE something else in the context of the application.. and at this point you wish there was something (a plugin?) in eclipse, that would tell you - "hey noob..don't change this - it would affect this..." - Now, if you were to create something that does this for eclipse (plugin?) - where would you start? (tagging parts of scr code and introducing a depdency tree? etc?)

A: 

What about JDepend?

AndreaG
+1  A: 

Perhaps I failed to understand your question, but I think I might have an answer. Take a look at nWire for Java (or PHP). It is a plugin for code exploration. Focusing on a piece of code, the developer can quickly determine where the method is invoked, where the class is used, etc. This makes it easier to understand what you are about to change.

I am the developer of this plugin. If it is not exactly what you are looking for, let me know, I'll be happy to better understand what you are looking for.

zvikico
@zvikico I just checked the demo of nWire. It looks pretty, but what I want is very different.. Imagine this.. Say you have a "Project" and "Resource" working on a project. Obviously, code is not self-aware, but I am talking about possible ways where you change something in a Project (a functional change) that would change the way the application behaves with respect to "resourcing accessing a project" - I guess.. its a shitty example.. but I hope it made sense?
Jay
alrite.. I read..what i added and it made no sense to me.. :-( Here is another example.. say you have a shareware application, and you are about to register it, so there is this "Name" and "Key" prompt. And, say in the code there is a check which goes like this: if(key generated from name) = <something> then make program registered else fail;Now, if I change the if condition to != instead of =, that changes the way the program behaves, wouldn't it? Wouldn't it be great if your IDE somehow warned about what you are possibly going to impact?
Jay
You are modifying a piece of code. This code affects all the pieces of code using it. Plain and simple. If you have knowledge of what those pieces are, you know what's going to be affected. Naturally, you should continue and explore this dependencies to determine all the areas that might change. So, I don't see the difference. Is it just from the UI perspective? (i.e. I changed the code, I want to know which parts of my UI will be affected?)
zvikico
@zvikico "If you have knowledge of what those pieces are, you know what's going to be affected" - correct. We are talking about eliminating this one developer having knowledge concept. When the developer codes it, he knows, but once this developer who coded the app leaves, a newbie would take a lot of time to make sense out of dependencies. Is there is an easier way out? Is there an approach?
Jay
So, technically speaking, you are looking for the ability to find a transitive closure of invokers of a given method. That will give you a good idea of what might be affected by a given change.
zvikico
+1  A: 

Besides: ALT+SHIFT+C is the way to change a method signature. ALT+SHIFT+G "only" finds references, which is helpful of course.

vickirk mentionend the most important aspect here: Without having tests and a good code coverage you aren't able to apply any changes without risking a failing system afterwards.

The book "Working Effectively with Legacy Code" from Robert C Martin explains it nicely: All code, which is not covered by tests, is legacy code. You could draw the conclusion, that before you apply any functional change you need to ensure a sufficient test coverage.

Tagging parts in the source code seems like a bad idea, since these tags need to be additionally maintained, which usually never really happens in projects. :)

pimpf0r
+1 for tagging = bad idea
Jay