Java 我应该如何可视化我的代码结构？

How should I visualize the structure of my code?

提问by Roman

I have an application written in Java. In is stored in several files. It uses different classes with different methods. The code is big and complicated. I think it would be easier to understand the code if I have a graphical model of the code (some kind of directed graph). Are there some standard methods for visualization of code. I am thinking about usage of UML (not sure it is a correct choice). Can anybody recommend me something?

我有一个用 Java 编写的应用程序。In 存储在几个文件中。它使用具有不同方法的不同类。代码又大又复杂。我认为如果我有代码的图形模型（某种有向图），会更容易理解代码。是否有一些标准的代码可视化方法。我正在考虑使用 UML（不确定这是一个正确的选择）。有人可以向我推荐一些东西吗？

ADDED:

添加：

I consider two possibilities:

我考虑两种可能：

1. Creating the graph by hands (explicitly).
2. Creating graph in an automatic way. For example to use some tools that read the available code and generate some graph describing the structure of the code.

1. 手动创建图形（明确）。
2. 以自动方式创建图形。例如，使用一些工具读取可用代码并生成一些描述代码结构的图形。

ADDED 2:

添加 2：

It would be nice to have something for free.

如果有免费的东西就好了。

采纳答案by Erick Robertson

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.

您没有理由必须使用任何一种标准的可视化方法，您可以使用任何您喜欢的媒体。纸、白板、photoshop、visio、powerpoint、记事本：所有这些都可以发挥作用。绘制类、对象、方法、属性、变量的图表 - 任何你认为对理解应用程序有用的东西。听众不仅是您团队的其他成员，还有您自己。创建有助于您查看和快速理解的图表。将它们张贴在您的工作空间周围并定期查看它们，以在构建时提醒自己整体系统架构。

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.

UML 和其他代码文档标准对于您可以绘制的图表类型以及您应该考虑包含的信息是很好的指南。但是，对于大多数应用程序来说，它是矫枉过正的，并且基本上存在于那些无法在没有标准的情况下对文档进行个人责任的人。如果您完全遵循 UML，您最终将花费太多时间在您的文档上，而不是创建您的应用程序。

回答by nanda

Some plugins I know for Eclipse:

我知道的一些 Eclipse 插件：

Architexa

建筑

http://www.architexa.com/

http://www.architexa.com/

nWire

nWire

http://www.nwiresoftware.com/

http://www.nwiresoftware.com/

If you want to reverse engineer the code, you should try Enterprise Architect

如果你想对代码进行逆向工程，你应该试试Enterprise Architect

回答by duffymo

JUDE Community UMLused to be able to import Java, but it is no longer the case. It is a good, free tool.

JUDE Community UML曾经可以导入 Java，但现在已经不是这样了。这是一个很好的免费工具。

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.

您不需要详细说明每个方法、参数和返回值。通常它只是您需要的对象或包之间的关系和交互。

回答by Jan Schierkolk

have you tried Google CodePro Analytix?

你试过Google CodePro Analytix吗？

it can for example display dependencies and is free (screenshot from cod.google.com):

例如，它可以显示依赖项并且是免费的（来自 cod.google.com 的屏幕截图）：

回答by haschibaschi

Here is a non UML Tool which has very nice visualization features.

这是一个非 UML 工具，它具有非常好的可视化功能。

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/

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

好消息是，您可以使用 Smalltalk 脚本来显示您需要的内容：http: //www.moosetechnology.org/docs/faq/JavaModelManipulation

Here you can see how such a visualization looks like: http://www.moosetechnology.org/tools/moosejee/casestudy

在这里你可以看到这样一个可视化的样子：http: //www.moosetechnology.org/tools/moosejee/casestudy

回答by Vineet

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.

我尝试使用了许多 UML 工具，发现大多数 UML 工具中的逆向工程功能对理解代码没有帮助。他们专注于设计需求和逆向工程能力往往最终只会显示大量无用信息的巨幅图片。当我在 Microsoft Office 代码库上工作时，我发现使用纸笔比使用典型的设计/建模工具更有帮助。

You typically want to think about doing this in a number of ways:

您通常需要考虑以多种方式执行此操作：

1. 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.
2. Find documentation and talk to co-workers: There is no better way than having some source describe the main conceptsin 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.
3. 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.
4. 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.

1. 动动脑筋：其他人提到了它 - 没有什么可以替代实际尝试理解代码库。您可能需要记下笔记，稍后再参考。工具能帮上忙吗？确实。但是不要指望他们会为您完成大部分工作。
2. 查找文档并与同事交谈：没有比让一些来源描述代码库中的主要概念更好的方法了。如果你能找到帮助你的人，带上笔和纸，去找他并做很多笔记。打扰另一个人多少钱？一开始 - 尽可能多地适合您的工作，但不要太少。
3. 考虑工具：如果您不熟悉项目的一部分 - 您将花费大量时间来理解代码，所以看看您可以自动获得多少帮助。有好的工具和坏的工具。首先尝试找出哪些工具具有可能对您有所帮助的功能。正如我上面提到的，一般的 UML 工具更侧重于建模，似乎不适合您。
4. 时间与成本：当然，免费很棒。但是，如果许多人没有使用免费工具 - 可能是该工具不起作用。有许多工具只是为了探索可以做什么而创建的，但并没有真正有用，因此只是免费提供，希望其他人能够采用它。另一种思考方式，决定你的时间值多少钱 - 花一两天时间让工具为你工作可能是有意义的。

Once there, keep these in mind when going trying to understand the project:

到达那里后，在尝试理解项目时请记住这些：

1. The Mile High View: A layered architectural diagram can be really helpful to know how the main conceptsin a project are related to one another. Tools like Lattixand Architexacan be really helpful here.
2. 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 AgileJand Architexaare your best bets here, but your average UML tool can often be good enough.
3. 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, JDeveloperand Architexaare your best bets here.

1. 一英里高视图：分层架构图对于了解项目中的主要概念如何相互关联非常有帮助。Lattix和Architexa等工具在这里非常有用。
2. 核心：尝试弄清楚代码在主要概念方面是如何工作的。类图在这里特别有用。笔和纸在这里经常工作，但工具不仅可以加快流程，还可以帮助您保存和共享此类图表。我认为AgileJ和Architexa是您最好的选择，但您的普通 UML 工具通常已经足够好了。
3. 关键用例：我建议至少为您的应用程序跟踪一个关键用例。您可能可以从团队中的任何人那里获得最重要的用例，并且逐步完成它会非常有帮助。大多数 IDE 在这里真的很有帮助。如果您尝试绘制它们，那么序列图是最合适的。对于这里的工具，我认为MaintainJ、JDeveloper和Architexa是您最好的选择。

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.

注意：我是 Architexa 的创始人 - 我们构建工具来帮助您理解和记录 Java 代码，但我已经尽量做到不偏不倚。我的目的是建议工具和选项，因为这是我在博士期间关注的重点。

回答by jens

Here is a another tool that could do the trick: http://xplrarc.massey.ac.nz/

这是另一个可以解决问题的工具：http: //xplrarc.massey.ac.nz/

回答by Choudary Kothapalli

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.

所有在校外编写的 Java 代码都是这样，特别是对于开始一个项目的新开发人员而言。

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.

这是一个老问题，但随着 Google 搜索中出现此问题，我将在此处添加我的回复，以便对未来的访问者有用。让我也透露一下，我是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.

当我这么说时，请相信我 - 具有 10 多年扎实编码经验的开发人员可能无法理解应用程序的某些部分如何工作，即使在同一个项目上工作了一年多之后（假设他们不是最初的开发人员）。他们可能不了解身份验证如何工作或事务管理如何在应用程序中工作。我说的是具有 1000 到 2000 个类并使用不同框架的典型企业应用程序。

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.

有两个重要的技能可以帮助他们做到这一点。

1. 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.

2. 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.

1. 他们能够分析他们在修复错误时所做的更改的影响。首先，他们找到问题，更改代码并对其进行测试以确保其有效。然后，因为他们非常了解 Java 语言和“足够好”的框架，他们可以判断它是否会破坏应用程序的任何其他部分。如果没有，它们就完成了。

2. 我说他们只需要模仿来增强应用程序。为了有效地模仿，人们需要很好地了解 Java 并“足够好”地理解框架。例如，当他们添加一个新的 Struts Action 类并添加到配置 xml 时，他们会首先找到一个类似的功能，尝试遵循该功能的流程并了解它是如何工作的。他们可能需要调整一些配置（例如“请求”范围内的“表单”数据而不是“会话”范围内的数据）。但是，如果他们“足够好”地了解这些框架，他们就可以轻松地做到这一点。

The bottom line is, you don't need to understandwhat all the 2000 classes are doing to fix a bug or enhance the app. Just understand what's needed.

最重要的是，您不需要了解所有 2000 个类正在做什么来修复错误或增强应用程序。只要明白需要什么。

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?

那么我是在阻止你理解架构吗？一点都不。我只要求你交付。一旦您开始了一个项目并在您的 PC 上设置了开发环境，您交付的时间不应超过一周，无论它多么小。如果你是一个有经验的程序员，两周后没有交付任何东西，经理怎么知道你是在工作还是在阅读体育新闻？

So, to make life easier for everyone, deliversomething. 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.

因此，为了让每个人的生活更轻松，请提供一些东西。不要抱着需要了解整个应用程序才能交付有价值的东西的态度。这是完全错误的。添加一个小型且本地化的 Javascript 验证可能对业务非常有价值，当您交付它时，经理会感到宽慰，因为他的钱物有所值。此外，它让您有时间阅读体育新闻。

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.

随着时间的流逝，在您交付 5 个小修复之后，您将开始慢慢了解架构。不要低估了解应用程序各个方面所需的时间。给 3-4 天的时间来了解身份验证。可能需要2-3天才能了解交易管理。这实际上取决于应用程序和您之前在类似应用程序上的经验，但我只是给出了大概的估计。窃取修复缺陷之间的时间。不要要求那个时间。

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.

Haaa...我花了很长时间才提到图表:)。我首先披露我是MaintainJ 的作者，该工具可生成运行时序列图。让我告诉你它如何帮助你。

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.

MaintainJ 生成的序列图显示了单个用例的调用流和数据流。因此，在一个简单的序列图中，您可以看到为用例调用了哪些方法。因此，如果您正在修复一个错误，那么该错误很可能出现在其中一种方法中。只需修复它，确保它不会破坏其他任何东西并退出。

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.

如果您需要添加新功能，请找到一些与您需要开发的功能类似的其他功能，使用MaintainJ 了解该功能的调用流程，然后进行模仿。

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

对我上述论点的两个警告

1. 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).

2. 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.

1. 我提到添加代码比更改现有代码风险更小。因为您想避免更改，您可能会倾向于简单地复制现有方法并添加到其中，而不是更改现有代码。抵制这种诱惑。所有应用程序都有一定的结构或“一致性”。不要因为代码重复等不良做法而毁了它。您应该知道何时偏离了“均匀性”。请项目的高级开发人员更改。如果你必须做一些不遵循约定的事情，至少要确保它是小类的本地方法（200 行类中的私有方法不会破坏应用程序的美学）。

2. 如果您遵循上述方法，虽然您可以在行业中生存多年，但您将面临不了解应用程序架构的风险，这从长远来看是不利的。这可以通过进行更大的更改或减少 Facebook 时间来避免。当您有一点空闲时，花时间了解架构并为其他开发人员记录它。

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.

专注于直接价值并使用提供它的工具，但不要偷懒。工具和图表有帮助，但你也可以没有它们。您可以通过花一些时间在项目上的高级开发人员来遵循我的建议。

回答by Syed Priom

Some great tools I use -

我使用的一些很棒的工具 -

StarUML (allows code to diagram conversion)

StarUML（允许代码到图表转换）

MS Visio

微软视觉

XMind (very very useful for overview of the system)

XMind（对系统概览非常有用）

Pen and Paper!

笔和纸！

回答by Dane

You can use JArchitecttool, 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

您可以使用JArchitect工具，这是一个非常完整的工具，可以使用依赖关系图可视化您的代码结构，并使用CQlinq像数据库一样浏览源代码。JArchitect 对开源贡献者免费