I tried using a number of UML tools and found that the reverse-engineering capabilities in most UML tools were not helpful for understanding code. They focus on designing needs and reverse-engineering capabilities often just ends up showing huge pictures of lots of useless information. When I was working on the Microsoft Office codebase, I found using a pen-and-paper more helpful that the typical design/modelling tools.
You typically want to think about doing this in a number of ways:
Use your brain: Someone else mentioned it - there is no substitute to actually trying to understand a code base. You might need to take notes down and refer back to it later. Can tools help? Definitely. But don't expect them to do most of the work for you.
Find documentation and talk to co-workers: There is no better way than having some source describe the main concepts in a codebase. If you can find someone to help you, take a pen and paper, go to him and take lots of notes. How much to bug the other person? In the beginning - as much as is practical for your work, but no amount is too little.
Think about tools: If you are new to a part of a project - you are going to be spending a significant amount of time understanding the code, so see how much help you can get automatically. There are good tools and bad tools. Try to figure out which tools have capabilities that might be helpful for you first. As I mentioned above, the average UML tool focuses more on modeling and does not seem to not be the right fit for you.
Time vs Cost: Sure, free is great. But if a free tool is not being used by many people - it might be that the tool does not work. There are many tools that were create just as an exploration of what could be done, but are not really helpful and therefore just made available for free in hopes that someone else will adopt it. Another way to think about it, decide how much your time is worth - it might make sense to spend a day or two to get a tool to work for you.
Once there, keep these in mind when going trying to understand the project:
The Mile High View: A layered architectural diagram can be really helpful to know how the main concepts in a project are related to one another. Tools like Lattix and Architexa can be really helpful here.
The Core: Try to figure out how the code works with regards to the main concepts. Class diagrams are exceptionally useful here. Pen-and-paper works often enough here, but tools can not only speed up the process but also help you save and share such diagrams. I think AgileJ and Architexa are your best bets here, but your average UML tool can often be good enough.
Key Use Cases: I would suggest tracing atleast one key use case for your app. You likely can get the most important use cases from anyone on your team, and stepping through it will be really helpful. Most IDE's are really helpful here. If you try drawing them, then sequence diagrams arethe most appropriate. For tools here I think MaintainJ, JDeveloper and Architexa are your best bets here.
Note: I am the founder of Architexa - we build tools to help you understand and document Java code, but I have tried to be unbiased above. My intention is to suggest tools and options given that this is what I focused on as part of my PhD.
The most important tool you should use is your brain, and it's free.
There's no reason why you have to use any sort of standard method of visualization, and you can use whatever media you like. Paper, whiteboard, photoshop, visio, powerpoint, notepad: all of these can be effective. Draw a diagram of classes, objects, methods, properties, variables - whatever you think is useful to see in order to understand the application. The audience is not only other members of your team, but also yourself. Create diagrams that are useful for you to look at and quickly understand. Post them around your workspace and look at them regularly to remind yourself of the overall system architecture as you build it.
UML and other code documentation standards are good guidelines for the types of diagrams you can do and the information you should consider including. However, it is overkill for most applications and basically exists for people who can't take personal responsibility for documenting without standards. If you follow UML to the letter, you'll end up spending way too much time on your documentation instead of creating your application.
It is stored in several files. It uses different classes with different methods. The code is big and complicated.
All Java code written outside the school is like that, particularly for a new developer starting on a project.
This is an old question, but as this is coming up in Google searches, I am adding my response here so that it could be useful to the future visitors. Let me also disclose that I am the author of MaintainJ.
Don't try to understand the whole application
Let me ask you this - why do you want to understand the code? Most probably you are fixing a bug or enhancing a feature of the application. The first thing you should not try to do is to understand the whole application. Trying to understand the entire architecture while starting afresh on a project will just overwhelm you.
Believe me when I say this - developers with 10+ years of solid coding experience may not understand how certain parts of the application work even after working on the same project for more than a year (assuming they are not the original developers). They may not understand how the authentication works or how the transaction management works in the application. I am talking about typical enterprise applications with 1000 to 2000 classes and using different frameworks.
Two important skills required to maintain large applications
Then how do they survive and are paid big bucks? Experienced developers usually understand what they are doing; meaning, if they are to fix a bug, they will find the location of the bug, then fix it and make sure that it does not break the rest of the app. If they need to enhance a feature or add a new feature, most of the time, they just have to imitate an existing feature that does a similar thing.
There are two important skills that help them to do this.
They are able to analyze the impact of the change(s) they do while fixing a bug. First they locate the problem, change the code and test it to make sure that it works. Then, because they know the Java language well and the frameworks 'well enough', they can tell if it will break any other parts of the app. If not, they are done.
I said that they simply need to imitate to enhance the application. To imitate effectively, one needs to know Java well and understand the frameworks 'well enough'. For example, when they are adding a new Struts Action class and adding to the configuration xml, they will first find a similar feature, try to follow the flow of that feature and understand how it works. They may have to tweak a bit of the configuration (like the 'form' data being in 'request' than in 'session' scope). But if they know the frameworks 'well enough', they can easily do this.
The bottom line is, you don't need to understand what all the 2000 classes are doing to fix a bug or enhance the app. Just understand what's needed.
Focus on delivering immediate value
So am I discouraging you from understanding the architecture? No, not at all. All I am asking you is to deliver. Once you start on a project and once you have set up the development environment on your PC, you should not take more than a week to deliver something, however small it may be. If you are an experienced programmer and don't deliver anything after 2 weeks, how can a manager know if you really working or reading sports news?
So, to make life easier for everyone, deliver something. Don't go with the attitude that you need to understand the whole application to deliver something valuable. It's completely false. Adding a small and localized Javascript validation may be very valuable to the business and when you deliver it, the manager feels relieved that he has got some value for his money. Moreover, it gives you the time to read the sports news.
As time passes by and after you deliver 5 small fixes, you would start to slowly understand the architecture. Do not underestimate the time needed to understand each aspect of the app. Give 3-4 days to understand the authentication. May be 2-3 days to understand the transaction management. It really depends on the application and your prior experience on similar applications, but I am just giving the ballpark estimates. Steal the time in between fixing the defects. Do not ask for that time.
When you understand something, write notes or draw the class/sequence/data model diagram.
Diagrams
Haaa...it took me so long to mention diagrams :). I started with the disclosure that I am the author of MaintainJ, the tool that generates runtime sequence diagrams. Let me tell you how it can help you.
The big part of maintenance is to locate the source of a problem or to understand how a feature works.
MaintainJ generated sequence diagrams show the call flow and data flow for a single use case. So, in a simple sequence diagram, you can see which methods are called for a use case. So, if you are fixing a bug, the bug is most probably in one of those methods. Just fix it, ensure that it does not break anything else and get out.
If you need to enhance a feature, understand the call flow of that feature using the sequence diagram and then enhance it. The enhancement may be like adding an extra field or adding a new validation, etc. Usually, adding new code is less risky.
If you need to add a new feature, find some other feature similar to what you need to develop, understand the call flow of that feature using MaintainJ and then imitate it.
Sounds simple? It is actually simple, but there will be cases where you will be doing larger enhancements like building an entirely new feature or something that affects the fundamental design of the application. By the time you are attempting something like that, you should be familiar with the application and understand the architecture of the app reasonably well.
Two caveats to my argument above
I mentioned that adding code is less risky than changing existing code. Because you want to avoid changing, you may be tempted to simply copy an existing method and add to it rather than changing the existing code. Resist this temptation. All applications have certain structure or 'uniformity'. Do not ruin it by bad practices like code duplication. You should know when you are deviating from the 'uniformity'. Ask a senior developer on the project to review the changes. If you must do something that does not follow the conventions, at least make sure that it's local to a small class (a private method in a 200 line class would not ruin the application's esthetics).
If you follow the approach outlined above, though you can survive for years in the industry, you run the risk of not understanding the application architectures, which is not good in the long run. This can be avoided by working on bigger changes or by just less Facebook time. Spend time to understand the architecture when you are a little free and document it for other developers.
Conclusion
Focus on immediate value and use the tools that deliver that, but don't be lazy. Tools and diagrams help, but you can do without them too. You can follow my advice by just taking some time of a senior developer on the project.
JUDE Community UML used to be able to import Java, but it is no longer the case. It is a good, free tool.
If your app is really complex I think that diagrams won't carry you very far. When diagrams become very complex they become hard to read and lose their power. Some well chosen diagrams, even if generated by hand, might be enough.
You don't need every method, parameter, and return value spelled out. Usually it's just the relationships and interactions between objects or packages that you need.
发布评论
评论（10）
我尝试使用许多 UML 工具，发现大多数 UML 工具中的逆向工程功能对于理解代码没有帮助。他们专注于设计需求和逆向工程能力，结果往往只是显示大量无用信息的巨幅图片。当我在 Microsoft Office 代码库上工作时，我发现使用笔和纸比典型的设计/建模工具更有帮助。
您通常需要考虑通过多种方式执行此操作：
一旦到达那里，在尝试理解项目时请记住这些：
注意：我是 Architexa 的创始人 - 我们构建工具来帮助您理解和记录 Java 代码，但我已经尽力做到不偏不倚。我的目的是建议工具和选项，因为这是我作为博士学位的一部分所关注的内容。
I tried using a number of UML tools and found that the reverse-engineering capabilities in most UML tools were not helpful for understanding code. They focus on designing needs and reverse-engineering capabilities often just ends up showing huge pictures of lots of useless information. When I was working on the Microsoft Office codebase, I found using a pen-and-paper more helpful that the typical design/modelling tools.
You typically want to think about doing this in a number of ways:
Once there, keep these in mind when going trying to understand the project:
Note: I am the founder of Architexa - we build tools to help you understand and document Java code, but I have tried to be unbiased above. My intention is to suggest tools and options given that this is what I focused on as part of my PhD.
您应该使用的最重要的工具是您的大脑，而且它是免费的。
您没有理由必须使用任何类型的标准可视化方法，并且您可以使用您喜欢的任何媒体。纸张、白板、Photoshop、visio、powerpoint、记事本：所有这些都可以有效。绘制类、对象、方法、属性、变量的图表 - 任何您认为有助于理解应用程序的内容。观众不仅是团队的其他成员，还有你自己。创建有助于您查看和快速理解的图表。将它们张贴在您的工作空间中并定期查看它们，以提醒自己构建系统时的整体系统架构。
UML 和其他代码文档标准是您可以制作的图表类型以及您应该考虑包含的信息的良好指南。然而，对于大多数应用程序来说，它是多余的，并且基本上是为那些无法在没有标准的情况下承担个人责任的人而存在的。如果您严格遵循 UML，您最终会在文档上花费太多时间，而不是创建应用程序。
The most important tool you should use is your brain, and it's free.
There's no reason why you have to use any sort of standard method of visualization, and you can use whatever media you like. Paper, whiteboard, photoshop, visio, powerpoint, notepad: all of these can be effective. Draw a diagram of classes, objects, methods, properties, variables - whatever you think is useful to see in order to understand the application. The audience is not only other members of your team, but also yourself. Create diagrams that are useful for you to look at and quickly understand. Post them around your workspace and look at them regularly to remind yourself of the overall system architecture as you build it.
UML and other code documentation standards are good guidelines for the types of diagrams you can do and the information you should consider including. However, it is overkill for most applications and basically exists for people who can't take personal responsibility for documenting without standards. If you follow UML to the letter, you'll end up spending way too much time on your documentation instead of creating your application.
所有在校外编写的 Java 代码都是这样，特别是对于开始项目的新开发人员来说。
这是一个老问题，但由于谷歌搜索中出现了这个问题，我在这里添加我的回答，以便它对未来的访问者有用。我还要透露一下，我是 MaintainJ 的作者。
不要试图理解整个应用程序
让我问你这个问题 - 为什么你想理解代码？您很可能正在修复错误或增强应用程序的功能。您不应该尝试做的第一件事就是理解整个应用程序。在重新开始一个项目的同时试图理解整个架构只会让你不知所措。
请相信我，拥有 10 年以上扎实编码经验的开发人员即使在同一个项目上工作了一年多，也可能无法理解应用程序的某些部分是如何工作的（假设他们不是最初的开发人员）。他们可能不了解身份验证如何工作或事务管理如何在应用程序中工作。我说的是具有 1000 到 2000 个类并使用不同框架的典型企业应用程序。
维护大型应用程序所需的两项重要技能
那么他们如何生存并获得高额报酬呢？经验丰富的开发人员通常了解他们在做什么；这意味着，如果他们要修复错误，他们会找到错误的位置，然后修复它并确保它不会破坏应用程序的其余部分。如果他们需要增强某个功能或添加新功能，大多数时候，他们只需模仿具有类似功能的现有功能即可。
有两项重要技能可以帮助他们做到这一点。
他们能够分析修复错误时所做的更改的影响。首先，他们找到问题，更改代码并进行测试以确保其有效。然后，因为他们非常了解 Java 语言并且“足够了解”框架，所以他们可以判断它是否会破坏应用程序的任何其他部分。如果没有，他们就完成了。
我说他们只是需要模仿来增强应用程序。为了有效地模仿，需要很好地了解 Java 并“足够好”地理解框架。例如，当他们添加一个新的 Struts Action 类并添加到配置 xml 中时，他们会首先找到一个类似的功能，尝试遵循该功能的流程并了解它是如何工作的。他们可能需要调整一些配置（例如“请求”范围中的“表单”数据而不是“会话”范围中的数据）。但如果他们“足够了解”框架，他们就可以轻松做到这一点。
底线是，您不需要了解所有 2000 个类都在做什么来修复错误或增强应用程序。只要明白需要什么就可以了。
专注于提供即时价值
那么我是否在阻止您理解架构？不，一点也不。我所要求的只是交付。一旦你开始一个项目并在你的电脑上设置了开发环境，你应该不会超过一周的时间来交付一些东西，无论它有多小。如果你是一位经验丰富的程序员，并且在两周后没有交付任何内容，那么经理如何知道你是否真的在工作或阅读体育新闻？
因此，为了让每个人的生活更轻松，请交付一些东西。不要抱有这样的态度：您需要了解整个应用程序才能交付有价值的东西。这是完全错误的。添加一个小型的本地化 Javascript 验证可能对业务非常有价值，当您交付它时，经理会感到放心，因为他的钱物有所值。此外，它还让您有时间阅读体育新闻。
随着时间的推移，在你完成 5 个小修复之后，你就会开始慢慢理解这个架构。不要低估了解应用程序各个方面所需的时间。给予 3-4 天的时间来了解身份验证。可能要2-3天才能了解交易管理。这实际上取决于应用程序以及您之前在类似应用程序上的经验，但我只是给出大概的估计。节省修复缺陷之间的时间。不要问那个时间。
当你理解一些东西时，写下笔记或画出类/序列/数据模型图。
图表
哈...我花了这么长时间才提到图表:)。我首先透露我是MaintainJ（生成运行时序列图的工具）的作者。让我告诉您它如何帮助您。
维护的重要部分是找到问题的根源或了解某个功能的工作原理。
MaintenanceJ 生成的序列图显示了单个用例的调用流和数据流。因此，在简单的序列图中，您可以看到用例调用了哪些方法。因此，如果您正在修复错误，则该错误很可能位于其中一种方法中。只需修复它，确保它不会破坏其他任何东西，然后退出。
如果您需要增强某个功能，请使用序列图了解该功能的调用流程，然后进行增强。增强可能就像添加额外的字段或添加新的验证等。通常，添加新代码的风险较小。
如果你需要添加一个新功能，找到一些与你需要开发的功能类似的其他功能，使用MaintainJ了解该功能的调用流程，然后模仿它。
听起来很简单？它实际上很简单，但在某些情况下，您将进行更大的增强，例如构建全新的功能或影响应用程序基本设计的东西。当您尝试类似的操作时，您应该熟悉该应用程序并相当了解该应用程序的架构。
对我上述论点的两个警告
我提到添加代码比更改现有代码的风险更小。由于您想避免更改，因此您可能会想简单地复制现有方法并添加到其中，而不是更改现有代码。抵制这种诱惑。所有应用程序都具有一定的结构或“一致性”。不要因为代码重复等不良做法而毁掉它。你应该知道什么时候你偏离了“一致性”。请项目的高级开发人员审查更改。如果您必须做一些不遵循约定的事情，至少要确保它是一个小类的本地方法（200 行的类中的私有方法不会破坏应用程序的美观）。
如果您遵循上述方法，尽管您可以在行业中生存多年，但您将面临不了解应用程序架构的风险，从长远来看这并不是一件好事。通过进行更大的改变或减少 Facebook 时间可以避免这种情况。当您有一点空闲时，花时间了解架构并为其他开发人员记录它。
结论
关注即时价值并使用可实现该价值的工具，但不要偷懒。工具和图表会有所帮助，但您也可以不使用它们。您可以遵循我的建议，只需花一些时间让高级开发人员参与该项目即可。
All Java code written outside the school is like that, particularly for a new developer starting on a project.
This is an old question, but as this is coming up in Google searches, I am adding my response here so that it could be useful to the future visitors. Let me also disclose that I am the author of MaintainJ.
Don't try to understand the whole application
Let me ask you this - why do you want to understand the code? Most probably you are fixing a bug or enhancing a feature of the application. The first thing you should not try to do is to understand the whole application. Trying to understand the entire architecture while starting afresh on a project will just overwhelm you.
Believe me when I say this - developers with 10+ years of solid coding experience may not understand how certain parts of the application work even after working on the same project for more than a year (assuming they are not the original developers). They may not understand how the authentication works or how the transaction management works in the application. I am talking about typical enterprise applications with 1000 to 2000 classes and using different frameworks.
Two important skills required to maintain large applications
Then how do they survive and are paid big bucks? Experienced developers usually understand what they are doing; meaning, if they are to fix a bug, they will find the location of the bug, then fix it and make sure that it does not break the rest of the app. If they need to enhance a feature or add a new feature, most of the time, they just have to imitate an existing feature that does a similar thing.
There are two important skills that help them to do this.
They are able to analyze the impact of the change(s) they do while fixing a bug. First they locate the problem, change the code and test it to make sure that it works. Then, because they know the Java language well and the frameworks 'well enough', they can tell if it will break any other parts of the app. If not, they are done.
I said that they simply need to imitate to enhance the application. To imitate effectively, one needs to know Java well and understand the frameworks 'well enough'. For example, when they are adding a new Struts Action class and adding to the configuration xml, they will first find a similar feature, try to follow the flow of that feature and understand how it works. They may have to tweak a bit of the configuration (like the 'form' data being in 'request' than in 'session' scope). But if they know the frameworks 'well enough', they can easily do this.
The bottom line is, you don't need to understand what all the 2000 classes are doing to fix a bug or enhance the app. Just understand what's needed.
Focus on delivering immediate value
So am I discouraging you from understanding the architecture? No, not at all. All I am asking you is to deliver. Once you start on a project and once you have set up the development environment on your PC, you should not take more than a week to deliver something, however small it may be. If you are an experienced programmer and don't deliver anything after 2 weeks, how can a manager know if you really working or reading sports news?
So, to make life easier for everyone, deliver something. Don't go with the attitude that you need to understand the whole application to deliver something valuable. It's completely false. Adding a small and localized Javascript validation may be very valuable to the business and when you deliver it, the manager feels relieved that he has got some value for his money. Moreover, it gives you the time to read the sports news.
As time passes by and after you deliver 5 small fixes, you would start to slowly understand the architecture. Do not underestimate the time needed to understand each aspect of the app. Give 3-4 days to understand the authentication. May be 2-3 days to understand the transaction management. It really depends on the application and your prior experience on similar applications, but I am just giving the ballpark estimates. Steal the time in between fixing the defects. Do not ask for that time.
When you understand something, write notes or draw the class/sequence/data model diagram.
Diagrams
Haaa...it took me so long to mention diagrams :). I started with the disclosure that I am the author of MaintainJ, the tool that generates runtime sequence diagrams. Let me tell you how it can help you.
The big part of maintenance is to locate the source of a problem or to understand how a feature works.
MaintainJ generated sequence diagrams show the call flow and data flow for a single use case. So, in a simple sequence diagram, you can see which methods are called for a use case. So, if you are fixing a bug, the bug is most probably in one of those methods. Just fix it, ensure that it does not break anything else and get out.
If you need to enhance a feature, understand the call flow of that feature using the sequence diagram and then enhance it. The enhancement may be like adding an extra field or adding a new validation, etc. Usually, adding new code is less risky.
If you need to add a new feature, find some other feature similar to what you need to develop, understand the call flow of that feature using MaintainJ and then imitate it.
Sounds simple? It is actually simple, but there will be cases where you will be doing larger enhancements like building an entirely new feature or something that affects the fundamental design of the application. By the time you are attempting something like that, you should be familiar with the application and understand the architecture of the app reasonably well.
Two caveats to my argument above
I mentioned that adding code is less risky than changing existing code. Because you want to avoid changing, you may be tempted to simply copy an existing method and add to it rather than changing the existing code. Resist this temptation. All applications have certain structure or 'uniformity'. Do not ruin it by bad practices like code duplication. You should know when you are deviating from the 'uniformity'. Ask a senior developer on the project to review the changes. If you must do something that does not follow the conventions, at least make sure that it's local to a small class (a private method in a 200 line class would not ruin the application's esthetics).
If you follow the approach outlined above, though you can survive for years in the industry, you run the risk of not understanding the application architectures, which is not good in the long run. This can be avoided by working on bigger changes or by just less Facebook time. Spend time to understand the architecture when you are a little free and document it for other developers.
Conclusion
Focus on immediate value and use the tools that deliver that, but don't be lazy. Tools and diagrams help, but you can do without them too. You can follow my advice by just taking some time of a senior developer on the project.
我知道的一些 Eclipse 插件：
Architexa
http://www.architexa.com/
nWire
http://www.nwiresoftware.com/
如果您想反转设计代码，您应该尝试企业架构师
Some plugins I know for Eclipse:
Architexa
http://www.architexa.com/
nWire
http://www.nwiresoftware.com/
If you want to reverse engineer the code, you should try Enterprise Architect
您尝试过 Google CodePro Analytix 吗？
例如，它可以显示依赖项并且是免费的（来自 cod.google.com 的屏幕截图）：
have you tried Google CodePro Analytix ?
it can for example display dependencies and is free (screenshot from cod.google.com):
这是一个非 UML 工具，它具有非常好的可视化功能。
您可以将每个类/方法的代码行映射到矩形的颜色/边长。
您还可以显示类之间的依赖关系。
http://www.moosetechnology.org/
好处是，您可以使用 Smalltalk 脚本来显示您想要的内容需要：
http://www.moosetechnology.org/docs/faq/JavaModelManipulation
在这里你可以看到这样的可视化看起来如何：
http://www.moosetechnology.org/tools/moosejee/casestudy
Here is a non UML Tool which has very nice visualization features.
You can mapping the lines of code per class / method to colors / side lenght of rectangles.
You can also show the dependencies between the classes.
http://www.moosetechnology.org/
The nice thing is, you can use Smalltalk scripting for displaying what you need:
http://www.moosetechnology.org/docs/faq/JavaModelManipulation
Here you can see how such a visualization looks like:
http://www.moosetechnology.org/tools/moosejee/casestudy
JUDE Community UML 曾经能够导入 Java，但它现在不再是这样了。这是一个很好的免费工具。
如果你的应用程序真的很复杂，我认为图表不会带你走太远。当图表变得非常复杂时，它们就会变得难以阅读并失去其力量。一些精心挑选的图表，即使是手工生成的，也可能就足够了。
您不需要详细说明每个方法、参数和返回值。通常，您需要的只是对象或包之间的关系和交互。
JUDE Community UML used to be able to import Java, but it is no longer the case. It is a good, free tool.
If your app is really complex I think that diagrams won't carry you very far. When diagrams become very complex they become hard to read and lose their power. Some well chosen diagrams, even if generated by hand, might be enough.
You don't need every method, parameter, and return value spelled out. Usually it's just the relationships and interactions between objects or packages that you need.
这是另一个可以做到这一点的工具：
http://xplrarc.massey.ac.nz/
Here is a another tool that could do the trick:
http://xplrarc.massey.ac.nz/
您可以使用 JArchitect 工具，这是一个非常完整的工具，可以使用 依赖关系图，并使用 CQlinq。
JArchitect 对于开源贡献者是免费的
You can use JArchitect tool, a pretty complete tool to visualize your code structure using the dependency graph, and browse you source code like a database using CQlinq.
JArchitect is free for open source contributors
我使用的一些很棒的工具 -
StarUML（允许代码到图表的转换）
MS Visio
XMind（对于系统概述非常非常有用）
笔和纸！
Some great tools I use -
StarUML (allows code to diagram conversion)
MS Visio
XMind (very very useful for overview of the system)
Pen and Paper!