Sorry guys, due to a stupid bug some of you might have faced really long wait times while trying to explore a diagram. I apologize for that. The issue has been resolved and exploration should work much better now.
I agree that understanding an Open Source project without proper documentation is really hard. For the same reason we are trying to create this site (http://www.codemaps.org/s/Lucene_Core) to document open source projects. This is still in beta and we would be glad to hear your thoughts on it.
The current release of the Architexa Suite supports Java and we do have prototypes supporting other languages. Please contact us if you are interested at [email protected]
I know that methods and classes mutate and their functionalities change over time. And the day it 'strikes you :)' that it has become gnarly it is time to refactor. How you proceed to do that is a different issue.
Personally I haven't come across a set of guidelines having more in-depth solution than what I have tried to mentioned here which works in all cases. It is a question quite dependent on the type of project you are working on. I think the best person who can properly direct you is the Architect or somebody with experience who knows the project thoroughly.
Hey James
I understand its not always easy to implement the best practices on real application and I have amply mentioned that in the post. What I am implying is that if we keep these things in mind and at least make an conscious effort to follow them it does really help.
When I mean intuitive I mean something which will give a decent idea what that method or class is supposed to do. Also I am sure you must have some idea of how you can group code modules your project. Moreover looking at types of cohesion can give a decent idea of what elements can be grouped together.
We are letting people in slowly for the trial version of our tool to provide good support. I would suggest you to sign up here (http://www.architexa.com/) and we will get back to you. Thanks for showing interest in our product.
Although there are open source projects which are quite bad, I still think being open source does motivate one to write better code. Regardless, having tools at your disposal to quickly understand/ document code for yourself and maybe relay your ideas to others can be really helpful.
I agree that the current code study tools are hard to use and we need something more intuitive. Many tools show too much information and are hard to learn. Is this what you meant when you said that the UI was tedious and bloated?
I agree to your point that that we need to write more understandable code(whatever the influences may be). By tools I meant some application which would help me understand already available code (well written or otherwise). Something which would quickly let me jump into the code and start working even when I do not have any background information about the code base.
These all are very good points but well written code is not easy to find and tools which help one to quickly understand code become really important in such cases.
Good point! We have been debating this. As the resource was small in the shown case the dialog just popped up for a split second. The reason why we have it is because nothing else can be done when processing is happening and if the resource is large it takes a little longer to process, so it makes sense to have a dialog there for that period. Any suggestions about how it can be made better are welcome.
Agreed , having a buddy really helps get things in perspective. Moreover, I work in a startup where direction of things get changed really fast. Not sure having remote people in this type of scenario will work.