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

Question

我有一个用Java编写的应用程序.In存储在多个文件中.它使用不同的类和不同的方法.代码又大又复杂.如果我有代码的图形模型(某种有向图),我认为理解代码会更容易.是否有一些标准的代码可视化方法.我正在考虑使用UML(不确定它是一个正确的选择).谁能推荐我一些东西？

添加:

我考虑两种可能性:

1. 手动创建图形(显式).
2. 以自动方式创建图形.例如,使用一些工具来读取可用代码并生成一些描述代码结构的图形.

增加2:

有免费的东西会很高兴.

Answer 1

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

您通常希望以多种方式考虑这样做:

1. 使用你的大脑:其他人提到它 - 实际上试图理解代码库是没有替代品的.您可能需要记下笔记并稍后再参考.工具有帮助吗？当然.但是不要指望他们为你做大部分的工作.
2. 查找文档并与同事交谈:没有比使用某些源描述代码库中的主要概念更好的方法了.如果你能找到帮助你的人,请拿笔和纸,去找他并记下很多笔记.对另一个人造成多大的伤害？在一开始 - 尽可能多的是你的工作,但没有数量太少.
3. 想想工具:如果您不熟悉项目的一部分 - 您将花费大量时间来理解代码,因此请查看您可以自动获得多少帮助.有很好的工具和糟糕的工具.尝试找出哪些工具具有可能对您有所帮助的功能.正如我上面提到的,平均UML工具更侧重于建模,似乎不适合您.
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.

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 concepts in a project are related to one another. Tools like Lattix and Architexa can be really helpful here.
2. 核心:尝试弄清楚代码如何与主要概念相关.类图在这里特别有用.笔在纸上的工作经常就足够了,但工具不仅可以加快流程,还可以帮助您保存和共享这些图表.我认为AgileJ和Architexa是你最好的选择,但你的平均UML工具通常都足够好.
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, 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.

Answer 2

你应该使用的最重要的工具是你的大脑,它是免费的.

您没有必要使用任何标准的可视化方法,您可以使用您喜欢的任何媒体.纸,白板,photoshop,visio,powerpoint,记事本:所有这些都可以有效.绘制类,对象,方法,属性,变量的图表 - 无论您认为什么是有用的,以便了解应用程序.观众不仅是您团队的其他成员,也是您自己.创建有助于您查看和快速理解的图表.将它们发布在您的工作区周围并定期查看它们,以便在构建时提醒您自己的整体系统架构.

UML和其他代码文档标准是您可以执行的图表类型以及您应该考虑的信息的良好指南.然而,对于大多数应用来说,它是过度的,并且基本上存在于没有标准的情况下不能承担个人责任的人.如果你遵循UML的话,你最终会花费太多时间在你的文档上,而不是创建你的应用程序.

Answer 3

它存储在几个文件中.它使用不同的类和不同的方法.代码又大又复杂.

在学校外面编写的所有Java代码都是这样的,特别是对于从项目开始的新开发人员.

这是一个老问题,但是随着谷歌搜索的出现,我在这里添加我的回复,以便它对未来的访问者有用.我还要透露我是MaintainJ的作者.

不要试图理解整个应用程序

我问你这个问题 - 你为什么要理解代码？很可能您正在修复错误或增强应用程序的功能.您不应该尝试做的第一件事是了解整个应用程序.尝试在项目重新开始时理解整个架构只会让你感到压力.

相信我这样说 - 具有10年以上固体编码经验的开发人员可能无法理解应用程序的某些部分即使在同一个项目上工作超过一年(假设他们不是原始开发人员)也是如此.他们可能无法理解身份验证的工作原理或事务管理在应用程序中的工作方式.我说的是具有1000到2000个类并使用不同框架的典型企业应用程序.

维护大型应用程序所需的两项重要技能

然后他们如何生存并获得巨额收入？经验丰富的开发人员通常了解他们在做什么; 意思是,如果他们要修复一个bug,他们会找到bug的位置,然后修复它并确保它不会破坏应用程序的其余部分.如果他们需要增强功能或添加新功能,大多数情况下,他们只需模仿现有功能即可.

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

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

2. 我说他们只需要模仿来增强应用程序.为了有效地模仿,需要很好地了解Java并且"足够好"地理解框架.例如,当他们添加新的Struts Action类并添加到配置xml时,他们将首先找到类似的功能,尝试遵循该功能的流程并了解其工作原理.他们可能不得不调整一些配置(比如'''''''''''''''''''''''''''''''''''''''''''''' 但如果他们知道框架"足够好",他们就可以很容易地做到这一点.

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

专注于提供即时价值

所以我劝你不要理解架构吗？一点都不.我所要求的只是提供.一旦你开始一个项目,一旦你在你的PC上设置了开发环境,你不应该花费超过一个星期的时间来交付一些东西,无论它多么小.如果您是一名经验丰富的程序员,并且在2周后没有提供任何服务,那么经理如何知道您是否真的在工作或阅读体育新闻？

所以,为了让每个人的生活更轻松,交付一些东西.不要采取你需要了解整个应用程序以提供有价值的东西的态度.这完全是假的.添加一个小的本地化Javascript验证可能对业务非常有价值,当您交付它时,经理对他的钱有一些价值感到宽慰.此外,它为您提供了阅读体育新闻的时间.

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

当您理解某些内容时,请编写注释或绘制类/序列/数据模型图.

图

哈...我花了很长时间才提到图:).我开始披露我是MaintainJ的作者,这是生成运行时序列图的工具.让我告诉你它是如何帮助你的.

维护的重要部分是找到问题的根源或了解功能的工作原理.

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

如果需要增强功能,请使用序列图了解该功能的调用流程,然后对其进行增强.增强可能类似于添加额外字段或添加新验证等.通常,添加新代码的风险较小.

如果您需要添加新功能,找到一些类似于您需要开发的功能,请使用MaintainJ了解该功能的呼叫流程,然后模仿它.

听起来很简单？它实际上很简单,但是在某些情况下,您将进行更大的增强,例如构建一个全新的功能或影响应用程序基本设计的东西.当您尝试这样的事情时,您应该熟悉应用程序并合理地理解应用程序的体系结构.

我上面的论点有两点需要注意

1. 我提到添加代码比改变现有代码风险更小.因为您想避免更改,所以您可能只想复制现有方法并添加到它而不是更改现有代码.抵制这种诱惑.所有应用都具有一定的结构或"均匀性".不要因代码重复等不良做法而毁掉它.你应该知道何时偏离"一致性".请项目高级开发人员查看更改.如果你必须做一些不符合约定的事情,至少要确保它是一个小类的本地(200行类中的私有方法不会破坏应用程序的美学).

2. 如果您遵循上述方法,虽然您可以在行业中存活多年,但您可能会面临不了解应用程序体系结构的风险,从长远来看这并不好.这可以通过更大的变化或更少的Facebook时间来避免.花时间了解架构,当你有点免费并将其记录给其他开发人员.

结论

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

Answer 4

我知道Eclipse的一些插件:

Architexa

http://www.architexa.com/

nWire

http://www.nwiresoftware.com/

如果要对代码进行反向工程,则应尝试使用Enterprise Architect

Answer 5

你试过Google CodePro Analytix吗？

它可以显示依赖关系并且是免费的(来自cod.google.com的屏幕截图):