★ FEATURED ARTICLE 接手一个乱成一团的旧模块时我最先做的事往往不是埋头读代码而是让IDEA帮我把类图画出来。没错就是我们每天都在用的IntelliJ IDEA它内置的UML工具远比多数人想象得实用不需要额外安装复杂的建模软件也几乎不用手动拖拽右键几下就能把项目结构摊开在眼前。这篇文章想和你聊聊我在实际项目里怎么用IDEA画UML图从最基本的类图生成到序列图、依赖关系、导出到文档再到那些会让你卡半天的坑我都会结合自己的实操经历掰开讲。1. 先搞清楚IDEA里的UML到底能做什么1.1 它和PlantUML这类工具有什么区别在开始操作前我觉得有必要先说清楚一个容易混淆的点IDEA自带的UML图和你可能用过的PlantUML工具压根不是一回事。PlantUML是靠写文本代码再渲染成图适合把设计阶段的想法快速画出来改起来方便也能放进版本控制里做diff。而IDEA自带的UML是逆向工程式的它不要求你画图它会直接扫描项目里的Java类、接口、枚举把它们的继承、实现、关联关系自动画出来。换句话说一个是从设计稿生成图一个是从代码反推图两者适用的场景完全不同。这样说可能还不太直观我打个比方PlantUML像是你用文字描述一栋楼的户型然后再让软件帮你铺开平面图而IDEA的UML功能像是站在已经盖好的楼里直接给你一张带标注的实测图。对于一个正在开发中、会不停改动的项目来说实测图的价值往往更高因为代码一改图就不会撒谎。这也是我为什么会在代码评审、模块梳理、接手老项目时第一时间打开IDEA类图的原因。顺带一提IDEA里其实也能装PlantUML插件在Markdown或者专门的.puml文件里写文本、渲染视图。我个人的习惯是设计阶段用PlantUML表达意图代码落地后用IDEA自带图确认现实。两种工具有一定的互补性但如果你今天的目标只是快速看懂项目结构那完全不需要额外折腾直接用IDEA自带功能就够了。1.2 版本和License层面的注意事项说到用IDEA自带UML第一件事要确认你手上的版本到底支不支持。这里有个很多新同事问过我的问题为什么我右键Java类没有Diagrams选项答案往往不是操作错了而是用的IDE版本不对。IDEA Community与Ultimate都支持基本的类图但支持的深度有差别。Ultimate版对依赖分析、模块关系、框架模型等支持更完整Community版通常在基础类图上也能正常工作。如果你的项目里有Spring这种框架Ultimate还可以结合框架模型生成更贴近业务概念的图这一点社区版就要弱一些。所以如果你发现自己只是想在两个类之间快速看一下关系社区版基本够用但如果你要的是整个模块的依赖视图建议用Ultimate或者退而求其次在社区版里只画小范围的类图。还有一个容易忽略的点把IDEA升级到较新版本后某些老项目引用的UML插件可能被默认隐藏或者禁用需要到插件市场重新启用。遇到右键看不到Diagram的情况时先不要怀疑IDEA坏了进Settings里的Plugins搜索UML把相关插件状态恢复试试。这个操作很简单却能解决大半的没有Diagram选项问题。2. 从零开始画第一张类图2.1 画图之前的小准备虽然工具本身很傻瓜化但进入画图流程之前我还是建议你先把准备工作做足否则后面容易一头雾水。首先要明确一点IDEA的类图是面向已有代码的它需要一个能被IDEA正常识别的项目结构。你要是打开一个裸目录里面只有几个散落的.java文件IDEA也能勉强画但包的层级、依赖关系可能很乱画出来参考价值不大。所以在画之前先确认项目能正常编译、模块结构清晰这是最基础的前提。其次建议你养成用快捷键的习惯。类图相关的快捷键不多记住两个就够用CtrlAltU用于在编辑器右侧打开类图CtrlAltShiftU用于弹出式的小窗类图。这里有个细节弹窗适合快速瞄一眼但不太适合做大范围的拖拽和整理想在图上操作比如右键添加相关类、导出图片最好还是用新标签页方式打开。我刚接触这个功能时喜欢用弹窗结果一拖动就发现它是个阉割版后来就改掉了这个习惯。如果你是在老一点的IDEA版本上菜单名称可能有差异比如有的版本叫Diagrams有的版本叫Show Diagram Popup还有的版本只有图标没有文字。不用慌先在类或包上右键看菜单里有没有UML相关的选项。实在找不到就用快捷键试快捷键往往比菜单更稳定。2.2 最常用的三种打开方式废话不多说直接上实操。假设你现在有个项目里面有一个UserService接口和它的实现类UserServiceImpl你想看看它们之间的关系最快的方式是在Project面板里或者在代码编辑器里把光标放在UserService这个接口名上按下CtrlAltUIDEA会新开一个标签页并把UserService作为图的中心展示出来如果还想看清UserServiceImpl不用重新生成图直接在图上右键选择Add Class to Diagram输入或选择对应的类名它就会被添加进当前这张图里。这个把类添加到当前图的操作非常实用很多人不知道导致他们每次看不同的类都要重新生成一遍图。事实上你完全可以像拼积木一样把关心的类一个个添加进来组合成一张局部关系图。比如你要给新同事讲一个订单流程你只需要把Order、OrderService、OrderRepository、OrderItem这几个类放到同一张图里它们之间的箭头和依赖关系就一目了然了。另一种打开方式是先选中多个类然后同时生成一张多类图。方法很直接在Project面板按住Ctrl多选几个类右键选择Diagrams下的Show DiagramIDEA会把所有选中的类放同一张图里并自动补全它们之间的连接关系。这个技巧在看一组类和另一组类的关系时特别有用尤其是确认模块边界的时候你选上A模块的几个核心类和B模块的几个核心类一眼就能看出两层之间到底有多少直接引用。最后一种也是最容易被忽视的在包名上右键选择Diagrams的Show Diagram。这会生成以包为范围的类图把所有类都铺出来某种程度上相当于一张包级地图。注意如果包下面类特别多第一次生成会比较慢而且图会非常大建议先在面板里缩小到能看清整体布局再用鼠标滚轮局部放大。我第一次用这个功能的时候生成的图上挤了两百多个类处理器差点转出噪音后来才知道可以先用结构筛选功能缩小范围。这里我真心建议假如你只需要快速看一两个类的关联用快捷键弹窗足够了但如果你是做模块梳理或者给团队做讲解一定要用新标签页方式然后花两分钟整理一下布局拖拽让关键类居中把不重要的类折叠起来。整理好的图导出给同事看比丢给他们一个原始的乱图有价值得多。2.3 认识类图上的符号和颜色图是画出来了但很多人看着满屏的箭头会觉得头大。其实IDEA类图的表达规则并不复杂花五分钟认一遍以后看任何图都顺畅。Java类在图上是个矩形顶部是类名中间是字段底部是方法。接口会标注为interface抽象类会标注为abstract枚举是enum这些标记都会直接显示在类名的位置不用你去猜。字段和方法前面通常有可见性图标绿点代表public红点代表private黄色或其他颜色代表 protected 或包内可见和代码里的语义一一对应。你在图上看到的每一条信息本质上都是从代码里读出来的不会出现图里写了但代码里没有的情况。箭头方面最核心的是继承和实现关系实线加空心三角箭头表示继承虚线加空心三角箭头表示接口实现这是UML的通用规则IDEA也是这么画的。此外代码里某个类持有另一个类的字段图里通常会有一条关联线线上可能标注着字段名或数量关系你可以右键关联线查看具体引用内容。依赖关系比如某个方法参数里出现了另一个类一般表现为虚线箭头。记住这三类就够了实线三角是继承虚线三角是实现普通虚线箭头是依赖。剩下的细节你完全可以看图说话。很多人会在这时候问图里能不能显示每个方法的具体签名当然可以。默认情况下IDEA会尽量显示完整的字段和方法签名但为了节省空间有时会折叠。你可以在类图上右键选择相关显示选项切换字段、构造器、方法等显示粒度甚至可以选择只显示公有成员。发表到文档里的图我一般会调整为只显示公有方法去掉getter/setter之类的噪音图一下子清爽很多。这部分的最后提醒一句图只是视图不是代码。在类图里直接对某个类右键你会发现一些类似的跳转源码入口。千万不要想着在图上改动代码结构IDEA没有提供这个能力你改不了类的定义只能看。真正改动还是得回到编辑器图会自动同步刷新。2.4 一次完整的实战演练空讲语法毕竟不够直观我拿一个常见的场景串一遍完整流程。假设你刚进一个项目组导师丢给你一个模拟项目X让你先梳理一下订单模块大概有哪些类、关系怎样。我建议你这样操作第一步在Project面板里展开业务包找到OrderController。这个类一般是入口先对它右键选择Diagrams里的Show Diagram生成以它为中心的图。第二步在图上右键OrderController选择Add Class to Diagram把OrderService、OrderServiceImpl、OrderRepository、OrderItem、OrderStatus这些相关的类都添加进来。你不需要一次性加太多加三五个看清楚一轮再决定下一轮要加谁。第三步点一下工具栏上的自动布局按钮IDEA会把当前的几个类重新排布一下箭头关系尽量不交叉。第四步对着图从OrderController顺着箭头往下走口中把每个类的作用念一遍念到哪个类不明确就双击它跳到源码去看一眼再回到图里继续。这套动作看起来简单但就是把一张图从生成出来变成能用的关键。很多人的误区是生成完图就直接放大看细节跳来跳去结果图还是那张乱图自己也没看明白顺序。实际上先加类、再布局、再顺着箭头走查这套流程走完你基本就能对模块有个清晰的框架认识了。3. 让类图真正为项目服务3.1 快速跳转代码的小技巧很多人的IDEA类图画完之后看几眼就关了之后再也不打开我觉得挺可惜的。因为类图在代码导航方面真的很猛尤其是刚接手一个大项目时你完全可以把它当成一张知识地图用。比如你在类图上看到UserServiceImpl和UserRepository之间有一条关联线你想知道到底是哪个字段产生的关联不需要去猜把鼠标放在关联线上IDEA会高亮相关信息如果想直接跳到代码位置右键这条线通常能找到导航相关的菜单项点了就能直接跳到持有该字段的代码行。这个操作比在编辑器里一次次用快捷键找实现、找引用要直观多了因为你能同时看到谁和谁有关联而不是一个个点下去。另外在类图上右键一个方法你还可以直接查看它的调用者和被调用者选Show Callers或者Show ImplementationsIDEA会弹出一个小列表列出相关的代码位置。这在梳理核心业务逻辑时效率极高我经常把它叫作顺着图走查代码从入口类开始一直顺着关联线找到底层实现中间不需要切回编辑器超过三次整个链路就能理清楚。还有一种更高级的用法双击类图里的某个类会跳到对应的源码双击接口的三角箭头可能会展开接口的实现列表IDEA会把实现该接口的多个类都展示出来还会问你到底想看哪一个。这种交互方式特别适合在重构前确认这个接口有哪些实现类各自分布在哪比全局搜索一份实现列表然后逐个打开要省事得多。3.2 多类图和模块大图的生成思路之前说的都是单类图和小范围多类图这里展开讲讲模块级的大图怎么生成、怎么用。当你面对的是一个几十个类的中型模块时我建议不要直接在整个包上生成图散得不行。正确的做法是分层生成先看最外层的门面类Controller、Service接口这些生成一张只包含这些核心类的图理清楚入口之间的关系然后再挑几个关键的核心类向图里追加它们的实现类、数据访问层、模型等逐步把细节补上。这样做的好处是每一张图的信息量都是可控的看一眼不会觉得崩溃而且每一张图都能放到文档里讲清楚一段逻辑。具体操作上你可以先选中一个门面类用快捷键生成图然后右键依次选择Add Class to Diagram把相关的类补进来。补的同时不要贪多尽量只添加有直接关系的类否则图会迅速膨胀成一团乱麻。我见过同事把几十个类全都放到一张图里最后别说同事连他自己都找不到重点在哪。如果你的需求就是整个包一起看请在包上右键生成全部类图之后先借助IDEA的布局和筛选功能做减法。在类图空白处右键菜单里有Layout相关选项可以调整自动布局方案选中某个类后可以选择折叠其内部成员或者隐藏它与其他类的某些关联线。只看你想讲的重点区域把周边弱相关的内容折叠起来这张大图才真正有可读性。这里额外说一个和架构梳理关系密切的功能IDEA在较新的版本里提供了分析依赖的工具比如在Project面板里选中某个包或模块右键可以查看它的依赖分析。不过这个功能在不同版本里叫法和位置差别很大最稳妥的方法还是用类图自己梳理。反正工具只是辅助核心是你要能对着图讲清楚这个模块依赖了谁谁又依赖了这个模块。3.3 图和代码不同步的问题类图是自动从代码生成的所以在绝大多数情况下只要代码一变、类图重新打开或者刷新它就会跟着变。但这里有个特别容易让新人误解的地方IDEA的类图并不会在代码保存的瞬间魔法般更新当前已经打开的标签页。我实测下来当你改动类结构后回到图标签页它通常会提示你要不要更新图或者你需要在图上右键选择刷新之类的操作。如果你发现图里显示的还是旧结构先别急这不是你操作错了而是图的缓存机制在起作用。解决办法很简单在图的标签页上右键选择刷新相关选项或者干脆把图标签页关掉重新生成一次。我在实际项目里一般选重新生成因为刷新的行为在某些版本里并不稳定你明明改了接口它刷新后可能还保留着旧节点需要手动删除反而浪费时间。另外如果你的同事给了你一张导出的类图截图然后你们对着截图开会讨论代码结构最后发现截图和当前代码对不上……这种情况其实特别常见解决思路也很简单截图只用于演示真正做决策的时候请以实时生成的图为准。我的习惯是开会前用IDEA现生成一张图投屏给大家看而不是拿一张P好的或者导出的旧图去讲不然讲到一半有人改了代码你讲的东西就失真了。提示导出图片前最好先在图里把要讲的重点高亮或折叠好导出内容就是你看到的内容。这可以说是IDEA UML功能最大的魅力了它不是一个独立的设计工具而是长在代码上的一双眼睛。图永远跟代码保持同步至少在你主动刷新之后这一点是外部任何绘图工具都很难替代的。3.4 用类图辅助重构前的风险判断除了用来理解现状类图在重构场景里的价值同样被低估。每次在动手抽类、拆分模块之前我都会先画几张和改动相关的类图不是画给别人看而是给自己做体检。最典型的场景是这个类越写越大我想拆开。你不要先动手复制代码先右键这个类生成图把它相关的依赖、被谁引用全部看一遍。图上一旦显示这个类被二十个地方引用你就要停下来想想贸然把它拆开要动多少调用方。如果关联线密密麻麻说明这个类已经是事实上的中心节点拆它得有个过渡方案而不是一把梭。还有一种场景是检查循环依赖。两个类互相持有对方的字段在类图上会呈现出明显的双向箭头。单看代码很难一眼发现这种问题但图上的双向箭头非常扎眼。每次看到这种箭头我都会回到两边的源码里确认一次到底是真循环还是只是相互引用然后记录下来作为后续优化的候选清单。我自己还有个习惯会在重构完成后再生成一次图和重构前的图截图放一起对比。不用多说什么箭头数量减少、依赖变清爽成果直观可见。这种可视化的对比在向团队汇报重构成果时真的非常省口舌。4. 序列图、依赖图和其他补充工具4.1 时序图能不能自动生成聊完类图肯定会有人问IDEA能不能直接画时序图这里的答案要分两层IDEA自带的UML工具并不包含自动时序图功能它主要专注静态结构也就是类图。但是这并不代表你在IDEA里就画不出时序图只是你通常需要借助第三方插件。市场上有一些第三方Sequence Diagram插件安装之后你可以在一个方法上右键选择生成该方法的时序图。工具会分析方法的调用链把你从入口方法调到的其他方法、对象之间交互按时间先后列成一张竖向的时序图。流程大体是先安装插件然后右键方法名选生成时序图再在弹出的设置里选择调用深度、是否包含getter/setter等点生成等上几秒到几十秒一张时序图就出来了。这里给你一个来自实际踩坑的提醒生成时序图时一定要控制调用深度和范围否则结果会非常庞大。我曾经在一个方法上直接生成全量调用链插件跑了将近一分钟出来的图上几千个节点根本没法看。后来我学乖了生成前把参数调到只显示当前类内部调用或者限制深度在3层以内图一下子变得可用多了。时序图本质是帮助理解流程的不是帮助你穷举所有执行路径的限制范围才是正确用法。如果你不想额外装插件另一个替代方案是利用IDEA的调用层次视图。具体操作是把光标放在方法名上按CtrlAltHIDEA会打开一个调用层次面板显示谁调用了这个方法以及这个方法又调用了谁。你一层层展开虽然本质上不是时序图的形态但也能顺着调用链理解执行顺序。需要说明的是这比真正的时序图抽象一些适合你只关心调用链而不需要精确时序的场合。4.2 依赖图和模块关系怎么看做模块拆分的同学一定关心IDEA能不能把模块之间的依赖关系画出来。好消息是IDEA在Ultimate版本里提供了比较完整的依赖分析能力可以把一个包、一个模块甚至整个工程的关系图生成出来坏消息是这个功能在不同版本里入口比较飘忽有时候在右键菜单里有时候在面板右上角的图标里需要你稍微翻一下。最通用的做法其实还得回到类图上。你可以在包或者模块的层级上生成类图然后用关系线来判断模块边界。假设你有一条规则上层模块不能依赖下层模块那么你在生成的包级图上如果看到不该出现的箭头那就是典型的依赖倒置信号。这种检查方式虽然没有专门的架构验证工具那么自动化但胜在直观、快速立刻就能看到是哪个类、哪条线破坏了规则。依赖分析方面IDEA里还有一个从Project面板出发的方法你可以选中多个模块右键选择Analyze的部分选项或者使用Analyze菜单里的Dependencies相关功能。弹出的分析结果会告诉你当前选择的范围依赖了哪些包、哪些类也能反过来查看谁引用了它。我一般会用这个功能做模块设计前的体检比如动工前先分析一下旧的模块依赖情况找出被很多地方引用的高危类提醒自己改动时要格外小心。我个人感觉IDEA内置依赖分析工具的作用是被很多人低估的。它不一定给你一张能直接放进文档的漂亮大图但它能快速回答这段代码还能不能动这个模块到底依赖了多少外部库这类问题。你要做的不是等着工具铺一张图而是学会看它给出的统计和依赖列表把它们作为你判断风险的依据。4.3 导出图片与打印文档图终于整理好了怎么把它放进设计文档或者评审材料里IDEA类图标签页的工具栏上有一个导出按钮通常是磁盘图标样式点击后可以导出成PNG、JPEG等常见图片格式。导出前一定要先调整好图的大小和布局因为导出的是所见即所得如果图本身又大又乱导出出来的图片一样没法看。这里有个很关键的小技巧导出前先把图缩放到适中的比例然后右键选择全图适合窗口之类的选项让整张图都在可视区域内再点导出。不然你很可能导出成一张只截取了左上角一部分的图等打开图片才发现关键类根本不在画面里。另外如果图上类很多导出后的图片分辨率可能不够看你可以在导出设置里选择更高的分辨率或放大导出比例再不行就拆成多张小图分别导出。除了存成图片你还可以直接把图内容复制到剪贴板粘贴进文档。在类图工具栏里通常也能找到复制到剪贴板相关选项粘贴之后依然保持着比较高的清晰度。我个人在写技术方案时很依赖这个复制功能因为它比截图更干净没有多余的窗口边框字体也大小一致整体观感好很多。如果你是给团队或客户做PPT讲解建议导出图片后先在外部画图工具里简单画个框、标个重点再把关键类用高亮圈出来。虽然IDEA本身也支持在图上做一些标注但标注功能相对简陋更多时候我会在最后一公里的美化上交给外部工具处理。这不是说IDEA的导出不行而是够用和好看之间还是有差距的你按自己场景权衡就好。5. 踩坑实录与问题排查速查表5.1 右键没有Diagram选项怎么办这个坑排在我个人最常被问榜单的第一名。明明照着教程操作右键Java类却看不到图相关选项很多人第一反应是IDEA坏了或者版本太旧。其实最可能的原因有三个插件被禁用、项目结构类型问题、或者你把光标放在了非Java文件上。先说插件问题。打开Settings找到Plugins搜索UML相关的插件检查它的状态是否为Enabled。如果它显示Disable启用后重启IDEA再回来右键试试。注意有些版本里UML插件可能默认没有勾选你不主动启用就永远看不到Diagram菜单。再说项目结构问题。如果你打开的目录不是IDEA识别的项目根目录或者这个文件没有被包在源码根目录下IDEA对你的类没有完整的模型UML菜单可能就不会出现。这种情况常见于直接打开一个文件夹、没有识别成Module的场景。解决方法是先确认项目能正常构建、文件图标是正常的Java类图标不是文本文件图标再试一次。最后还有一种情况非常容易忽略当你在一个未保存的.kt文件上右键或者在一些非Java成员比如变量名、字符串上右键时右键菜单里不会出现Diagram选项。所以请把光标放在类名上或者放在类型声明那行再试试看。排除完这三类基本都能解决问题。5.2 大项目里类图卡顿明显怎么办生成一张包含几百个类的图IDEA卡上几十秒甚至更久这在老机器上特别常见。如果你遇到这种情况先别急着关闭IDEA有几个实用的缓兵之计。第一图生成之前尽量缩小范围。不要直接在总包上生成全量大图而是先选中你真正关心的几个类用小范围图起步。这一点前面说过算是最大的经验教训。第二在类图标签页里把自动布局切换成手动布局或者使用更简化的布局模式减少IDEA反复计算连线的压力。第三如果还是卡可以在图里批量隐藏你不关心的成员比如把getter/setter折叠起来图的信息量小了渲染的负担自然下降。如果你的机器实在带不动还有一个终极方案直接装PlantUML插件用文本描述方式生成图。这种方式不依赖IDEA不停分析整个项目模型只根据你写的类名和关系出图性能稳定得多。当然代价是你要手动维护类清单不能像IDEA自带图那样从代码实时同步。我一般会这样取舍代码结构实时浏览用自带图性能实在扛不住的大图分析改用PlantUML或干脆换台更好的电脑。5.3 导出图片不清晰或者只有一部分导出图片时最容易出现的两个问题一个是导出内容不完整一个是图片发虚、看不清文字。这两个问题基本都是导出前的视图设置没调好。内容不完整通常是因为导出时窗口有滚动条而IDEA只是导出了当前可视区域。所以在你点导出前先让图完整缩放到视图中确保没有横向的滚动条或者使用适应窗口的选项让所有节点都在可视区域内。如果你想让导出图片保留更多细节就不要调到太小比例可以适当放大后再导出配合按比例导出或高清导出选项。图片发虚则一般是因为默认导出DPI不够高。在导出设置里通常可以调整缩放比例或DPI值你把它调高一些比如导出的图片在100%缩放下文字依然清晰再放到PPT或文档里就会舒服很多。如果支持导出SVG这种矢量格式部分版本支持那就更好了放大缩小都不失真。我自己的经验是导出前先多花两分钟看图确认没有重叠的节点、没有重叠的标签顺便调整一下画布大小让四周留一点边距导出效果就会大幅度提升。别等到导完图在文档里看半天发现字被截断了才回头重新调整那才是最浪费时间的。5.4 常见问题速查表现象最可能的原因快速解决右键找不到DiagramUML插件未启用Settings - Plugins - 启用后重启右键菜单有但生成空白图类未被IDEA识别到确认项目结构和源码根目录正常类图没有显示成员显示粒度被折叠右键图 - 显示选项 - 勾选字段/构造器/方法图与代码不同步标签页缓存未刷新重新生成图或手动刷新生成的图非常大范围太大/类太多先创建小范围图再逐步添加类导出图片不完整当前视图并非全图先适应窗口再导出导出图片文字模糊DPI不够高调高导出DPI/选择高清导出或SVG类图卡顿明显图规模大且自动布局缩小范围关闭自动布局这张表是我在实际使用中一点点攒下来的。如果你遇到表中没有覆盖到的问题我的建议是先看IDEA的官方帮助或者版本发布说明因为不同小版本之间UML功能的行为差别不小很多问题都是版本特定问题。6. 我的使用习惯与建议6.1 什么场景我必须用类图说了这么多工具细节最后讲一讲我真正依赖类图的几个场景或许能帮你想清楚自己在什么情况下值得打开它。第一个场景是接手老项目。不管是不是自己写的接手前先在关键入口、核心业务模块上生成几张类图花半小时顺着图走完主要调用链基本上就能对系统有个轮廓认知。我不建议一上来就逐行读代码那样很容易迷失在细节里先有全局再有局部效率完全不同。第二个场景是代码评审。评审一个涉及多个类变更的代码时我会让改代码的同事把改动相关的类图投出来对着图逐层分析依赖。这个方法能很快暴露出一些问题比如不该被依赖的类被强行引用了、循环依赖藏在角落里等比盯着diff一点点脑补强太多。第三个场景是写技术方案前。在文档里描述当前系统是这么组织的时用一张IDEA生成的实时类图作为现状基线然后再画目标架构图两者的对比会非常有说服力。基于现状的图不掺任何水分领导也好、同事也好看到的第一反应都是原来现在长这样方案评审的讨论一下子就有了锚点。6.2 一些能提升体验的习惯最后分享几个我长期使用的习惯不一定适合所有人但你可以试试看。比如项目里核心模块的类图我会固定导出一份放到文档库的指定路径下版本更新就重新导出每个版本对应一份图历史记录一目了然。虽然IDEA能实时生成但在追溯版本演变的时候存档图非常有用。再比如我会给类图里的关键类加颜色标记。IDEA支持在图上对单个类设置高亮颜色虽然支持得不算很透明但一些和业务强相关的重要类我会用颜色把它们和其他普通类区分开这样图一打开重要的内容先跳出来。如果你找不到这个功能也没关系不用强求颜色只是锦上添花。还有一个习惯是和同事协作时的讲代码设计时尽量用IDEA现生成的图为准不要拿一张可能过期的导出图讲太久。好多人问我为什么老是现场生成图因为现场生成的图永远不会说谎。我可以提前准备好要讲的范围和布局但结构一定以当前代码为准这样讲出来的东西落地性和可信度才高。6.3 最后再分享一个小技巧说到小技巧有一个我最近才彻底用顺的类图里的分层查看。在生成接口和实现类的关系图时IDEA默认会把所有直接实现者展示出来。如果你只是想看某个父类被哪些子类继承而不想看它们内部的方法完全可以在图上把子类的成员折叠起来或者设置显示模式为只显示类名。这样图会简洁很多就像在看一棵树的骨架而不是每片叶子都描了一遍。这个技巧在你梳理框架扩展点时特别有用。比如一个抽象类有十几个子类你只想确认哪些子类覆盖了哪些核心方法时可以把子类的成员都展开然后用肉眼或者颜色快速扫过去哪片区域高亮密集哪里就是扩展点比较活跃的地方下一步分析会非常有目标感。好了关于IDEA画UML这一点我把自己能想到的、试用过的方法和踩过的坑都写下来了。UML这东西理论上可以画得很复杂但实际你用到最多的还是那张类图。别被各种规范和符号吓住先把IDEA自带的类图用顺手再慢慢扩展其他图你会发现它是所有代码浏览工具里最像地图的那一个。
阅读完成 · 觉得有帮助？
