当程序员写代码就行了，为什么还要画图？

相信很多人选择当程序员除了这个行业起步阶段薪资比其他行业高一些之外，还有一个很大的因素是觉得做研发类的工作只要代码写的好，跟电脑这个“直男”打交道就可以了。

但是还没走出校门呢，毕业这一关就得边做毕业设计边写毕业论文。写毕业论文可不是直接把自己的实现代码从 IDE 粘贴到 Word 里，但凡代码多一点就会被老师要求修改，老师会告诉你要把你做的毕业设计的功能、设计思路、关键部分的实现细节用绘图结合文字表达清楚。

这时很多同学就犯难了，匆匆拿出大三的教材《软件程序设计》看看上面的那些的图都怎么画的，再找找网上的例子，模仿着能画出个类似下面的流程图。

上面这个图乍一看还可以，但是网上关于流程图的语法好几个版本，每个人画出来都不一样，而且用这种形式表达大一些的流程，就完全感觉眼花缭乱。

画图的底层逻辑是沟通

其实走到工作岗位上之后我们仍然面临着这样的问题，除了专心写代码外，我们的工作构成中还有大量的需求评审、需求分析、技术评审、系统方案设计这样的需要人和人进行沟通的环节，讲逻辑、讲实现方案、讲设计思路的沟通环节。究其原因就是因为 IT 行业分工明细，它像其他行业的工作流水线一样涉及大量工种的合作，但又因为交付的软件并不像工业流水线一样是标准件，所以上面列举的每个环节都需要良好的沟通，让各职能人员之间建立共识、建立统一语言后才能完成高效协作交付产品。

既然需要良好的沟通建立统一语言，那么我们在需求分析、技术评审、系统方案设计文档上就不能使用太主观的语言，也不能把实现代码直接往文档上粘，那样的话且不说有的岗位不写代码，即使同岗位的其他同事也没有那个精力一行一行的仔细看完你的代码、理解你的思路。

所以这就需要我们能够简洁、高效地用人们都能看懂的专业图形描述出软件开发这些环节中需要重点沟通的需求逻辑和技术的关键细节。

我们都知道从事理工专业的人，可能对构图、色彩这些不太擅长，那么有没有一种图形不需要美术基础就能掌握，足够专业让图形能突出我们想表达的技术细节，同时还足够简洁即使是不太懂技术的人也能完全看懂呢？在 IT 领域还真有，那就是 UML。

比如同样是表达需求的业务流程，用流程图表达的就是上面图-1 的那个样子，但是用表达力更强，更注重语法的 UML 活动图表达流程的话就是下面这个样子。

关于怎么用活动图分析表达流程，后面会有专门的章节去给大家讲解。

程序员画图难的成因

说到 UML，无论是大学里还是市面上讲解 UML 的书籍中对 UML 的讲解都太过枯燥了，它们通常都是以技术和软件设计的角度来讲述 UML 的，通常上来会先讲解一大堆图，哪些是结构建模，哪些是行为建模，紧接着就是各种图的一堆语法（画法），或者是给出的示例太过于技术化，完全脱离日常生活让人无法理解。

这就给我们这样一开始不太懂的人一种 UML 太过专业太过复杂，不好用的印象。想的那么清楚画出图来，代码早写好了。典型的例子就是如果画类图把类的各个属性和方法都想好画出来也太费时间了，况且需求多变还要经常改，还有就是那些类图表示的类的关系一会儿是箭头、一会儿是虚线、不明白他们都什么区别，看多了就头疼。

其实上面这个现象完全就是误区，UML 完全不是必须那么复杂–把所有细节都表示出来才算完事，我们完全可以从需求分析阶段开始就开始使用，在分析的过程中构思业务的结构并画出来它大概的样貌。