我应该如何可视化我的代码的结构？
我有一个用Java编写的应用程序。 存储在几个文件中。 它使用不同的类和不同的方法。 代码大而复杂。 我认为如果我有代码的graphics模型（某种有向图），将会更容易理解代码。 有没有一些标准的代码可视化方法。 我正在考虑使用UML（不知道这是一个正确的select）。 有人可以推荐我吗？
添加：
我考虑两种可能性：
- 手动（显式）创buildgraphics。
- 以自动方式创buildgraphics。 例如，使用一些读取可用代码的工具，并生成一些描述代码结构的graphics。
加2：
有免费的东西，这将是很好的。
你应该使用的最重要的工具是你的大脑，它是免费的。
为什么你不得不使用任何标准的可视化方法，你可以使用任何你喜欢的媒体。 纸，白板，photoshop，visio，powerpoint，记事本：所有这些都可以是有效的。 绘制类，对象，方法，属性，variables的图表 – 无论您认为哪些内容对于理解应用程序非常有用。 观众不仅是你的团队的其他成员，也是你自己。 创build对您有用的图表，并快速理解。 张贴在您的工作区周围，并定期看他们提醒自己整个系统架构，当你build立它。
UML和其他代码文档标准是您可以执行的图表types以及您应该考虑的信息的良好准则。 然而，对于大多数应用程序来说这是过度的，对于没有标准的人来说，不能承担个人责任。 如果你按照UML来写信，你最终会花费太多的时间在你的文档上，而不是创build你的应用程序。
我尝试过使用大量的UML工具，发现大多数UML工具中的逆向工程能力对理解代码没有帮助 。 他们专注于devise需求和逆向工程能力，最终往往会显示大量无用信息的巨大画面。 当我在Microsoft Office代码库上工作时，发现使用笔和纸比典型的devise/build模工具更有帮助。
您通常想要以多种方式考虑这样做：
- 使用你的大脑 ：其他人提到它 – 实际上试图理解代码库是没有替代的。 您可能需要记下笔记，稍后再返回。 工具可以帮助吗？ 当然。 但不要指望他们为你做大部分的工作。
- 查找文档并与同事交谈 ：有一些源代码描述代码库中的主要概念没有更好的方法。 如果你能find人来帮助你，拿一支纸和笔，去找他并且记下很多笔记。 有多less错误的对方？ 一开始 – 尽可能多地适合你的工作，但不要太less。
- 考虑一下工具 ：如果你对项目的一部分是陌生的 – 你将花费大量的时间来理解代码，所以看看你能自动获得多less帮助。 有好的工具和糟糕的工具。 尝试找出哪些工具具有可能对您有用的function。 正如我上面提到的，平均的UML工具更注重build模，似乎并不适合你。
- 时间与成本 ：当然，自由是伟大的。 但是，如果一个免费的工具没有被许多人使用 – 可能是工具不起作用。 有许多工具只是作为对可以完成的事情的探索而创build的，但并不真正有用，因此只是免费提供，希望其他人能够采用。 另一种思考方式，决定你的时间值多less – 花一两天才能find一个工具为你工作是有意义的。
一旦到了那里，在试图理解这个项目的时候记住这些：
- 英里高视图 ：分层的架构图可以真正帮助您了解项目中的主要概念是如何相互关联的。 像Lattix和Architexa这样的工具在这里真的很有用。
- 核心 ：试图弄清楚代码如何处理主要概念 。 类图在这里非常有用。 笔和纸在这里经常工作，但工具不仅可以加快进程，还可以帮助您保存和共享这样的图表。 我认为AgileJ和Architexa是你最好的select，但是你的平均UML工具往往足够好。
- 关键用例 ：我build议为您的应用程序追踪至less一个关键用例。 你可能会从你的团队中的任何人获得最重要的用例，并通过它将是非常有用的。 大多数IDE在这里真的很有帮助。 如果你尝试绘制它们，那么序列图就是最合适的。 对于这里的工具，我认为MaintainJ ， JDeveloper和Architexa是你最好的select。
注意：我是Architexa的创始人 – 我们构build的工具可以帮助您理解和loggingJava代码 ，但是我试图在上面没有偏见。 我的意图是build议工具和选项，因为这是我作为博士学位的一部分。
它存储在几个文件中。 它使用不同的类和不同的方法。 代码大而复杂。
所有在学校以外编写的Java代码都是这样的，尤其是对于一个从项目开始的新开发人员。
这是一个古老的问题，但是当谷歌search出现这个问题时，我在这里添加我的回应，以便对未来的访问者有用。 让我也透露我是MaintainJ的作者。
不要试图理解整个应用程序
让我问你这个 – 你为什么要了解代码？ 很可能你正在修复一个bug或增强应用程序的function。 你不应该试图做的第一件事是理解整个应用程序。 在重新开始一个项目的同时尝试理解整个架构将会压倒你。
当我这样说的时候相信我 – 具有10年以上扎实的编码经验的开发人员可能不知道，即使在同一个项目上工作一年以上（假设他们不是原始开发人员），应用程序的某些部分是如何工作的。 他们可能不了解身份validation如何工作，或者应用程序中的事务pipe理如何工作。 我正在谈论具有1000到2000个类别的典型企业应用程序，并使用不同的框架。
维护大型应用程序所需的两项重要技能
那么他们是如何生存下来并获得大笔资金的呢？ 有经验的开发人员通常会理解他们在做什么; 这意味着，如果他们要修复一个bug，他们会findbug的位置，然后修复它，并确保它不会破坏应用程序的其余部分。 如果他们需要增强function或添加新function，大多数情况下，他们只需要模仿现有function即可完成类似function。
有两个重要的技能可以帮助他们做到这一点。
-
他们能够分析修改bug的影响。 首先，他们find问题，更改代码并对其进行testing，以确保其正常工作。 然后，因为他们很了解Java语言和框架，所以他们可以判断是否会破坏应用程序的其他部分。 如果不是，他们就完成了。
-
我说他们只需要模仿来增强应用。 要有效地模仿，就需要对Java很好地了解，并且很好地理解框架。 例如，当他们添加一个新的Struts Action类并添加到configurationxml中时，他们将首先find一个类似的function，尝试关注该function的stream程并理解它是如何工作的。 他们可能需要调整一些configuration（比如“请求”中的“表单”数据比“会话”范围中的数据）。 但是如果他们知道框架“够好”，他们可以轻松地做到这一点。
底线是， 你不需要了解所有2000个类正在做什么来修复一个bug或增强应用程序。 只要了解需要什么。
专注于提供即时的价值
那么，我是否让你不理解这个架构呢？ 一点都不。 我问你的只是交付。 一旦你开始一个项目，并且一旦你在你的PC上build立了开发环境，你不应该花一个星期的时间来提供一些东西，尽pipe它可能很小。 如果你是一位经验丰富的程序员，2周后不能交付任何东西，那么经理怎么知道你是在工作还是在阅读体育新闻呢？
所以，为了让每个人的生活更轻松， 提供一些东西。 不要以你需要了解整个应用程序的态度来提供有价值的东西。 这是完全错误的。 添加一个小的，本地化的Javascriptvalidation可能对业务非常有价值，当您交付时，经理感到放心，他已经为自己的钱获得了一些价值。 此外，它给你的时间来阅读体育新闻。
随着时间的推移，你提供了5个小的修复程序，你会开始慢慢的了解这个架构。 不要低估了了解应用程序各个方面所需的时间。 提供3-4天的时间来了解身份validation。 可能2-3天才能了解交易pipe理。 这真的取决于应用程序和您以前的类似应用程序的经验，但我只是给大概的估计。 在修复这些缺陷之间偷点时间。 不要问那个时间。
当你理解了某些东西的时候，写下笔记或者绘制类/序列/数据模型图。
图
哈哈……花了我很长时间才提到图表:)。 我首先披露了我是MaintainJ的作者，这是生成运行时序图的工具。 让我告诉你它是如何帮助你的。
维护的重要部分是找出问题的根源或了解某个function的工作原理。
MaintainJ生成的序列图显示了单个用例的调用stream程和数据stream程。 所以，在一个简单的顺序图中，你可以看到为哪个用例调用了哪些方法。 所以，如果你正在修复一个bug，这个bug很可能就是其中一种方法。 只要修好它，确保它不会破坏任何东西，然后离开。
如果您需要增强function，请使用序列图了解该function的呼叫stream程，然后对其进行增强。 增强可能就像添加额外的字段或添加新的validation等。通常，添加新代码的风险较小。
如果您需要添加新function，请find与您需要开发的其他function相似的function，请使用MaintainJ了解该function的调用stream程，然后模拟该function。
听起来很简单？ 这其实很简单，但是会出现一些情况，比如构build一个全新的特性或者影响应用程序基本devise的东西。 当你尝试这样的事情时，你应该熟悉应用程序并理解应用程序的架构。
两个警告我上面的论点
-
我提到添加代码比改变现有代码风险更小。 因为你想避免改变，你可能会试图简单地复制现有的方法并添加到现有的方法，而不是改变现有的代码。 抵制这种诱惑。 所有应用程序都有一定的结构或“一致性”。 不要因代码重复等不良做法而毁了它。 你应该知道什么时候你偏离了“统一”。 请项目的高级开发人员检查更改。 如果你必须做一些不符合约定的事情，至less要确保它是本地的一个小class级（200线类中的私有方法不会破坏应用程序的美学）。
-
如果按照上面所述的方法进行操作，虽然可以在行业中生存多年，但是您仍然有可能无法理解应用程序体系结构，从长远来看这并不好。 这可以通过做更大的改变或者减lessFacebook时间来避免。 花点时间了解一下这个架构，当你有一点空闲时，为其他开发者logging下来。
结论
专注于立即的价值，并使用提供的工具，但不要懒惰。 工具和图表帮助，但你也可以没有他们。 你可以按照我的build议，只需要一些高级开发人员的项目。
我对Eclipse所了解的一些插件：
Architexa
nWire
如果您想对代码进行逆向工程，您应该尝试Enterprise Architect
你有没有试过Google CodePro Analytix ？
它可以例如显示依赖关系，并免费（从cod.google.com截图）：
JUDE社区UML曾经能够导入Java，但不再是这种情况。 这是一个很好的免费工具。
如果你的应用程序非常复杂，我认为这个图表不会让你走得很远。 当图表变得非常复杂时，它们变得难以阅读和失去它们的力量。 一些精心挑选的图表，即使是手工生成也可能就足够了。
你不需要每一个方法，参数和返回值的拼写。 通常这只是您需要的对象或包之间的关系和交互。
这是一个非UML工具，它具有非常好的可视化function。
您可以将每个类/方法的代码行映射到矩形的颜色/边长。 您还可以显示类之间的依赖关系。
http://www.moosetechnology.org/
好的是，你可以使用Smalltalk脚本来显示你所需要的： http : //www.moosetechnology.org/docs/faq/JavaModelManipulation
在这里你可以看到这样一个可视化的样子： http : //www.moosetechnology.org/tools/moosejee/casestudy
这是另一个可以做到这一点的工具： http : //xplrarc.massey.ac.nz/
您可以使用JArchitect工具，一个非常完整的工具，使用依赖关系图可视化您的代码结构，并使用CQlinq像浏览数据库一样浏览源代码。 JArchitect对于开源贡献者是免费的
我使用一些很棒的工具 –
StarUML（允许代码图转换）
MS Visio
XMind（对于系统的概述非常有用）
笔和纸！
