入手一个项目的时候，大佬们是怎样理清项目各个模块的

[bler]

有没有画图的必要，我搜了一下 uml ，但是大多数回答都是那玩意儿再如今的场景中，不太适用。

但是正向开发，需求确实不明确，画图有时候好像确实有那么点浪费时间，但是反过来，当一个项目成型多年，
一个新人接手这个项目的时候，我感觉画图又能构建起对整个项目更加清晰的认识。

有大佬这样做过吗，使用的什么工具梳理的这些东西，还是说全靠看，看到哪是哪，只关注自己干活所涉及到的模块，没有对整体模块做过梳理


我的需求是大佬们平时在梳理逻辑的时候，有没有画图，使用过什么画图工具，体验如何

[8355]

最简单的找产品约个会议室，从系统里给演示一遍，哪里有什么规则和操作逻辑边演示边讲就全通了。
自己跑一遍测试环境可以加深印象，然后根据系统路由看代码和数据表的关系最后看计划任务和队列类代码，善用搜索。
如果是服务类项目没有图形界面就从路由代码开始，大模型辅助分析业务流，挨个看其他一样。

[huifer]

有机会可以看看我在做的这个项目，然后我们可以深度交流一下。

这对你来说可能是一个完全未知的内容。

绘制 uml 是一个不错的选择，但是得看项目方是否提供了，如果没有提供的话要自己绘制这个消耗的就不只是时间了。

https://github.com/iot-ecology/rust-iot-platform

[Hopetree]

最近在看公司的一个产品的模块，妈的，被继承看晕了，真的是继承又继承继承又继承。。。一层套一层，刚以为自己找到了切入点，一用发现这个类不对，要找父类重新继承才能用

[kakawa]

看每个模块的创建逻辑

[kakki]

带着任务看项目

[sophos]

我这边的项目都可以直接基于代码生成模块间的依赖拓扑图 :-)

https://github.com/go-kod/kod-mono?tab=readme-ov-file#callgraph-auto-generated

[RandomJoke]

先了解业务，再了解各个模块的基本作用，带着任务再重点关注某个模块，大型项目维护文档是一件很费时间精力的事情，所以大部分大型项目文档不会那么细致，尤其业务优先的时代，项目中可能留了很多曾经有用，后来废弃的代码，或者不维护的代码