我有一个用 Java 编写的应用程序。In 存储在几个文件中。它使用不同的类和不同的方法。代码又大又复杂。我认为如果我有代码的图形模型（某种有向图）会更容易理解代码。是否有一些代码可视化的标准方法。我正在考虑使用 UML（不确定这是一个正确的选择）。有人可以推荐我一些东西吗？
添加：
我考虑两种可能：
- 手动创建图表（明确地）。
- 以自动方式创建图形。例如，使用一些工具来读取可用代码并生成一些描述代码结构的图表。
添加2：
有东西免费就好了。
问问题
29375 次
10 回答
25
我尝试使用了许多 UML 工具，发现大多数 UML 工具中的逆向工程功能对理解代码没有帮助。他们专注于设计需求和逆向工程能力往往只是显示大量无用信息的巨大图片。当我在 Microsoft Office 代码库上工作时，我发现使用笔和纸比典型的设计/建模工具更有帮助。
您通常需要考虑以多种方式执行此操作：
- 动动脑筋：其他人提到过 - 没有什么可以替代实际尝试理解代码库的。您可能需要记下笔记并稍后再参考。工具能帮上忙吗？确实。但不要指望他们会为您完成大部分工作。
- 查找文档并与同事交谈：没有比让一些源代码描述代码库中的主要概念更好的方法了。如果你能找到帮助你的人，拿笔和纸，去找他，做很多笔记。给别人多少麻烦？一开始 - 尽可能多地为您的工作提供实用性，但任何数量都不会太少。
- 考虑一下工具：如果您对项目的某个部分不熟悉 - 您将花费大量时间来理解代码，所以看看您可以自动获得多少帮助。有好工具和坏工具。首先尝试找出哪些工具具有可能对您有所帮助的功能。正如我上面提到的，一般的 UML 工具更侧重于建模，似乎并不适合您。
- 时间与成本：当然，免费很棒。但是，如果许多人没有使用免费工具 - 可能是该工具不起作用。有许多工具是为了探索可以做什么而创建的，但并没有真正的帮助，因此只是免费提供，希望其他人会采用它。另一种思考方式是，决定你的时间值多少钱——花一两天时间来获得一个为你工作的工具可能是有意义的。
到达那里后，在尝试了解项目时请记住以下几点：
- Mile High View：分层架构图对于了解项目中的主要概念如何相互关联非常有帮助。Lattix和Architexa等工具在这里非常有用。
- 核心：试着弄清楚代码是如何与主要概念相关的。类图在这里特别有用。纸笔在这里经常工作，但工具不仅可以加快流程，还可以帮助您保存和共享此类图表。我认为AgileJ和Architexa是您最好的选择，但您的普通 UML 工具通常就足够了。
- 关键用例：我建议为您的应用跟踪至少一个关键用例。您可能可以从团队中的任何人那里获得最重要的用例，并且逐步完成它会非常有帮助。大多数IDE在这里真的很有帮助。如果您尝试绘制它们，那么序列图是最合适的。对于这里的工具，我认为MaintainJ、JDeveloper和Architexa是你最好的选择。
注意：我是 Architexa 的创始人 - 我们构建工具来帮助您理解和记录 Java 代码，但我试图在上面保持公正。我的目的是建议工具和选项，因为这是我在博士期间关注的内容。
于 2010-10-07T01:56:13.760 回答
21
你应该使用的最重要的工具是你的大脑，而且它是免费的。
您没有理由必须使用任何类型的标准可视化方法，您可以使用任何您喜欢的媒体。纸张、白板、photoshop、visio、powerpoint、记事本：所有这些都可以发挥作用。绘制类、对象、方法、属性、变量的图表——任何你认为对理解应用程序有用的东西。观众不仅是您团队的其他成员，还包括您自己。创建有助于您查看和快速理解的图表。将它们张贴在您的工作区周围并定期查看它们，以在您构建它时提醒自己整体系统架构。
UML 和其他代码文档标准是您可以执行的图表类型以及您应该考虑包含的信息的良好指南。但是，对于大多数应用程序来说，它是矫枉过正的，并且基本上适用于那些无法在没有标准的情况下对文档负责的人。如果您不遗余力地遵循 UML，您最终将花费太多时间在文档上，而不是创建应用程序。
于 2010-10-06T11:43:29.533 回答
15
它存储在多个文件中。它使用不同的类和不同的方法。代码又大又复杂。
所有在校外编写的 Java 代码都是这样，特别是对于刚开始一个项目的新开发人员。
这是一个老问题，但随着谷歌搜索出现这个问题，我在这里添加我的回复，以便对未来的访问者有用。让我也透露一下，我是MaintainJ的作者。
不要试图理解整个应用程序
让我问你这个——你为什么要理解代码？很可能您正在修复错误或增强应用程序的功能。您不应该尝试做的第一件事是了解整个应用程序。在重新开始一个项目的同时试图理解整个架构只会让你不知所措。
当我这么说的时候请相信我——拥有 10 年以上扎实编码经验的开发人员即使在同一个项目上工作了一年多之后（假设他们不是最初的开发人员），也可能不理解应用程序的某些部分是如何工作的。他们可能不了解身份验证的工作原理或事务管理在应用程序中的工作原理。我说的是具有 1000 到 2000 个类并使用不同框架的典型企业应用程序。
维护大型应用程序所需的两项重要技能
那么他们如何生存并获得巨额报酬？经验丰富的开发人员通常了解他们在做什么；这意味着，如果他们要修复错误，他们会找到错误的位置，然后修复它并确保它不会破坏应用程序的其余部分。如果他们需要增强一个特性或添加一个新特性，大多数时候，他们只需要模仿一个现有的特性来做类似的事情。
有两个重要的技能可以帮助他们做到这一点。
他们能够分析他们在修复错误时所做的更改的影响。首先，他们找到问题所在，更改代码并对其进行测试以确保其正常工作。然后，因为他们非常了解 Java 语言并且框架“足够好”，所以他们可以判断它是否会破坏应用程序的任何其他部分。如果没有，他们就完成了。
我说他们只是需要模仿来增强应用程序。为了有效地模仿，需要很好地了解 Java 并“足够好”地理解框架。例如，当他们添加一个新的 Struts Action 类并添加到配置 xml 中时，他们会首先找到一个类似的功能，尝试遵循该功能的流程并了解它是如何工作的。他们可能需要调整一些配置（例如“请求”范围内的“表单”数据而不是“会话”范围内的数据）。但是，如果他们“足够好”地了解这些框架，他们就可以轻松做到这一点。
底线是，您无需了解所有 2000 个类都在做什么来修复错误或增强应用程序。只需了解需要什么。
专注于提供即时价值
那么我是在阻止你理解架构吗？一点都不。我只要求你交付。一旦你开始一个项目并在你的 PC 上设置好开发环境，你不应该花费超过一周的时间来交付一些东西，无论它多么小。如果你是一位经验丰富的程序员，但两周后没有交付任何东西，经理怎么知道你是真的在工作还是在阅读体育新闻？
因此，为了让每个人的生活更轻松，请提供一些东西。不要抱着你需要了解整个应用程序才能交付有价值的东西的态度。这是完全错误的。添加一个小型的本地化 Javascript 验证可能对业务非常有价值，当您交付它时，经理会因为他的钱物有所值而感到宽慰。此外，它让您有时间阅读体育新闻。
随着时间的推移，在您完成 5 个小修复后，您将开始慢慢了解架构。不要低估了解应用程序各个方面所需的时间。给 3-4 天时间来了解身份验证。可能需要 2-3 天才能了解交易管理。这实际上取决于应用程序和您之前在类似应用程序上的经验，但我只是给出大致的估计。在修复缺陷之间偷走时间。不要问那个时间。
当你理解一些东西时，写笔记或画出类/序列/数据模型图。
图表
哈......我花了这么长时间才提到图表:)。我从披露我是生成运行时序列图的工具 MaintainJ 的作者开始。让我告诉你它如何帮助你。
维护的重要部分是找到问题的根源或了解功能的工作原理。
MaintainJ 生成的序列图显示了单个用例的调用流和数据流。因此，在一个简单的序列图中，您可以看到为一个用例调用了哪些方法。因此，如果您正在修复错误，则错误很可能是其中一种方法。只需修复它，确保它不会破坏其他任何东西并离开。
如果您需要增强某个功能，请使用序列图了解该功能的调用流程，然后对其进行增强。增强可能就像添加额外的字段或添加新的验证等。通常，添加新代码的风险较小。
如果你需要添加一个新的特性，找一些和你需要开发的相似的特性，用MaintainJ理解那个特性的调用流程，然后模仿它。
听起来很简单？这实际上很简单，但在某些情况下，您将进行更大的增强，例如构建全新的功能或影响应用程序基本设计的东西。当你尝试这样的事情时，你应该熟悉应用程序并相当好地理解应用程序的架构。
我上面的论点有两个警告
我提到添加代码比更改现有代码的风险要小。因为您想避免更改，您可能很想简单地复制现有方法并添加到其中，而不是更改现有代码。抵制这种诱惑。所有应用程序都有一定的结构或“统一性”。不要因为代码重复等不良做法而毁掉它。您应该知道何时偏离“一致性”。请项目的高级开发人员审查更改。如果您必须做一些不遵循约定的事情，至少要确保它是小类的本地方法（200 行类中的私有方法不会破坏应用程序的美观）。
如果您遵循上述方法，尽管您可以在该行业中生存多年，但您会冒着不了解应用程序架构的风险，从长远来看这是不好的。这可以通过进行更大的更改或减少 Facebook 时间来避免。当您有一点空闲时，花时间了解架构并为其他开发人员记录它。
结论
专注于即时价值并使用能够实现这一目标的工具，但不要偷懒。工具和图表有帮助，但你也可以不用它们。你可以听从我的建议，只需花一些时间在项目上的高级开发人员身上。
于 2012-02-02T17:55:38.763 回答
10
于 2010-10-06T10:16:10.007 回答
9
于 2010-10-06T11:29:57.400 回答
4
这是一个非 UML 工具，它具有非常好的可视化功能。
您可以将每个类/方法的代码行映射到矩形的颜色/边长。您还可以显示类之间的依赖关系。
http://www.moosetechnology.org/
好消息是，您可以使用 Smalltalk 脚本来显示您需要的内容： http ://www.moosetechnology.org/docs/faq/JavaModelManipulation
在这里您可以看到这种可视化的样子： http ://www.moosetechnology.org/tools/moosejee/casestudy
于 2010-10-06T12:50:56.193 回答
3
JUDE Community UML以前可以导入Java，但现在已经不行了。这是一个很好的免费工具。
如果您的应用程序真的很复杂，我认为图表不会让您走得太远。当图表变得非常复杂时，它们变得难以阅读并失去作用。一些精心挑选的图表，即使是手工生成的，也可能就足够了。
您不需要详细说明每个方法、参数和返回值。通常，您需要的只是对象或包之间的关系和交互。
于 2010-10-06T11:14:59.123 回答
2
您可以使用JArchitect工具，这是一个非常完整的工具，可以使用依赖图可视化您的代码结构，并使用CQlinq像数据库一样浏览源代码。JArchitect 对开源贡献者是免费的
于 2014-10-28T15:25:42.307 回答
2
这是另一个可以解决问题的工具：http: //xplrarc.massey.ac.nz/
于 2011-08-22T00:48:16.457 回答
0
我使用的一些很棒的工具 -
StarUML（允许代码到图表的转换）
微软视觉
XMind（对于系统概览非常有用）
笔和纸！
于 2014-10-27T20:59:13.290 回答