写代码前有必要画类图吗？有画图经验的大神进

TeacherYoung 2016-09-18 06:08:02

软件开发好几年经验了，单对类图之类的架构知识一直没有深挖。对于这种图还有流程图之类的，基本都用到了开发完成后，闲的没事了画画、整理整理，以便留点遗产给后人，方便新人入手之类的。

但最近不知道哪蹦出来的感触：带兵打仗时元帅都是拿小纸人在地形图上排兵布阵的，这尼玛不就是程序开发前的画图阶段么：先不写代码，画出来看看通不通，不通就在图上改改，改好后再干活。

当然很多人不去画图的一大原因是：有画图的功夫能写出来好多代码呢……

这句话颇像：有磨刀的功夫我都多砍了好多柴了……

一开始很不熟练，画个简单的图都憋半个小时一个小时，但如果熟练后，编程前先花十几分钟把架构画出来，能很大程度上避免走入死胡同。

这是我最近的一个感触，不知道大神们如何看，与我们这些一开始就创建solution来架构的程序员相比，是否在写程序之前先打个设计的草稿，画画图？

另：如果要增加架构能力，有什么种类的图需要学习，如何增加自己画图的能力。请各位大神指教

...全文

2205 31 打赏收藏转发到动态举报

写回复

用AI写文章

31 条回复

切换为时间正序

请发表友善的回复…

发表回复

我扶奶奶过哈登 2016-09-21

打赏
举报

较大的工程（几百兆以上的软件）画图才真的有用，明确前台，后台，域，数据库等方面。写代码的时候各部分严格按照类图的依赖关系写，当需求发生变化时，也可以比较容易找到

丫的昵称好难想 2016-09-21

打赏
举报

思路清晰就不用画，复杂的想不清楚就可以画画。从来不画的路过....

长空X 2016-09-21

打赏
举报

引用 24 楼 xuanbg 的回复:

画个思维导图更简单些，表现能力也甩UML类图几条街。
引用 21 楼 hjkl950217 的回复:
[quote=引用 3 楼 caozhy 的回复:] vs自带code map以及反向uml工具，所以画图没有什么必要，画图的问题是，你的代码是不断变化的，你还得维护两个东西的同步。
是不是在VS里画好图了就能生成一部分代码？

你想多了。。。是根据代码自动生成类图。。。关于画图，新人强烈建议！！！画得一手好图的程序员才是一个合格的程序员，连图都不会画或画不好，也好意思称自己是程序员？最多就是码农罢了[/quote]画图我知道还是重要的。思维导图不是有点乱么？一个分支分太多东西出来了。。一直不知道用什么方式。。前辈能贴一个你觉得比较好的设计么？思维导图的。。我搜到的都比较乱

software_artisan 2016-09-20

打赏
举报

画个思维导图更简单些，表现能力也甩UML类图几条街。

引用 21 楼 hjkl950217 的回复:

引用 3 楼 caozhy 的回复:
vs自带code map以及反向uml工具，所以画图没有什么必要，画图的问题是，你的代码是不断变化的，你还得维护两个东西的同步。
是不是在VS里画好图了就能生成一部分代码？

你想多了。。。是根据代码自动生成类图。。。关于画图，新人强烈建议！！！画得一手好图的程序员才是一个合格的程序员，连图都不会画或画不好，也好意思称自己是程序员？最多就是码农罢了

qq_16573809 2016-09-20

打赏
举报

根据所操做的东西来决定是否画图

我叫小菜菜 2016-09-20

打赏
举报

引用 18 楼 MrMicrosoft 的回复:

引用 3 楼 caozhy 的回复:
vs自带code map以及反向uml工具，所以画图没有什么必要，画图的问题是，你的代码是不断变化的，你还得维护两个东西的同步。
确实，一开始可能可以保持同步，但是到后面，感觉画图部分有点累赘，我是做小项目的，大的不清楚

这么耿直我喜欢。我也是做小项目的，进坑时发现除了代码和数据库，其他啥都没有。连文档都懒得写的团队，怎么可能画流程图、类图、数据流图呢。用例图之类的更不用想了，都是在验收阶段需要提交时才补上的。画图用visio挺好用的，国产的亿图也不错，甚至有人直接在Word里面画的，没啥奇怪。

长空X 2016-09-20

打赏
举报

引用 3 楼 caozhy 的回复:

vs自带code map以及反向uml工具，所以画图没有什么必要，画图的问题是，你的代码是不断变化的，你还得维护两个东西的同步。

是不是在VS里画好图了就能生成一部分代码？

长空X 2016-09-20

打赏
举报

引用 2 楼 xiaha3 的回复:

画图有三个阶段性目的：一摸象，最有用的就是流程图，用例图，手画图（最有用），其他参考参考visio，很多uml图，涉及到软件的uml图大多只是对自己有用，因为大多程序员不懂，客户更不懂，而且一般设计师就一个，所以交流起来最有用的是流程图和框图二完善设计对于完善设计，这了要特别强调一下，绝不是为了生成代码，而是直观，便于分析思考。软件设计的内容主要两个方面，一个是数据分类上的，一个是数据处理上的，也就是一个是空间上的，一个是时间上的。现在的uml图大多都有，但是还有些东西没有，需要自己画图描述。另，语言描述是最清晰的，超过所有的图，大体设计出来后，会有多个 uml的图，基本就是解耦过的，因为uml没有那种大而全的表现图，每个图都只是表示一个方面，但是解耦的程度和水平决定于设计师，也许解的超烂，也许解的明晰三构造代码类图和序列图就比较有用，写代码不走神，要不总是回忆下一步应该干啥最后说一句架构能力在于技术掌握的熟练度，很多设计模式都内置在高级语言和工具里面了，技术是设计的支撑，熟练了，设计就能够自行脑补，反过来，学了设计架构，还是等于原始人打仗

感谢经验分享！

小灰狼 2016-09-20

打赏
举报

引用 3 楼 caozhy 的回复:

vs自带code map以及反向uml工具，所以画图没有什么必要，画图的问题是，你的代码是不断变化的，你还得维护两个东西的同步。

+1 另外，画图主要是为了交流，同时留下点东西能够让自己在过个一年半载之后还能想起以前系统里解决问题的思路如果画个图成为开发和交流的累赘，那么图就不必要画了所以，一般我画图，一般是画粗略的图，描述大概的解决方案思路即可，详细的图放到代码注释里会更好一点。

xiaha3 2016-09-20

打赏
举报

引用 25 楼 zapdos 的回复:

[quote=引用 13 楼 xiaha3 的回复:] [quote=引用 11 楼 zapdos 的回复:] 小需求就没必要了多组协作的话，总体架构和基础接口是必需的

你说的都是画图之后的工作了，解构了模块，确定了模块职责，就不需要画设计图了大项目从需求到设计，到模块接口，到分工，说起来就太多了。总体架构和基础接口一出来，项目基本上就完成了一大半。基本上就已经消灭了风险，往下就是控制工期的事情了。如果大家想往设计上凑，建议大家看看用例图和活动图，看这两个图，不是让大家学习这两个图，而是明白设计师调研需求都应该做哪些工作，当然一直拿模块做代码的，就没必要了[/quote]

谁跟你说是画图之后的工作，系统分析、设计、需求评审这些你都靠嘴？[/quote] 我说的是总体架构和基础接口

chinaxkk 2016-09-20

打赏
举报

我一开始也尝试过画图然后我被画图搞炸了不如一边写一边想有问题去找之前的备注还是蛮快的这个我个人觉得因人而异吧一个小程序员的独白

xiejin90314 2016-09-20

打赏
举报

不需要呀代码没写之前数据结构项目结构已然呈现在心里面好了承认我是装逼的

zapdos 2016-09-20

打赏
举报

引用 13 楼 xiaha3 的回复:

[quote=引用 11 楼 zapdos 的回复:] 小需求就没必要了多组协作的话，总体架构和基础接口是必需的

谁跟你说是画图之后的工作，系统分析、设计、需求评审这些你都靠嘴？

xiaha3 2016-09-19

打赏
举报

再说一下，画图绝不是为了生成代码，是了解需求，分析需求，解构架构的过程，一般来说uml不是必须的，为了自己看也可以手画些不规范的图，过于规范的图一般在分析的后期，前期容易分散精力，也容易陷入歧途。
关于图最后应该到达的什么样的粗细粒度，就看图能否清晰分解模块职责，图的目的就达到了。
很多程序如果直接在脑中形成模块职责，就可以直接用语言集成的工具画类图，写个骨架，大部分高级语言有这个功能。然后直接写代码，然后不断完善，再说下，画类图是为了确定有哪些代码要写，防止翻来覆去找下一步该干啥，类图是很必要的，建议用集成的工具做