| 实用工具
在 画图 —— 程序员必备的神技 一文中,我们已经了解了画图的好处以及一些实际的画图工具/方式。
然而,可能有些朋友还有很多疑惑。
到底,什么时候画什么图比较合适呢?
而且,即使已经知道了这些图,我该怎么画?
其实,只要开始行动,一切就没有想象中那么困难了。
Ficow 在学习新知识的时候喜欢搞清楚3个问题。只要搞清楚这几个问题,就很容易进入下一步:
是什么?
为什么
我需要它?(它存在的理由)怎么用
它?建议您也试试给自己提问,这样可以帮助自己快速抓住重点并理解这些内容
!
接下来,让我们来逐步探索并回答文章标题中的几个问题:何时画图?画什么图?如何画图?
关于这个问题,Ficow 的建议是:
不管您以后想绘制 C4 还是 UML,您都需要熟悉相关的基础知识。然而,画图其实是一个非常实操性的技能,不练手肯定没办法真正吸收相关的内容。所以,在练手阶段,建议您尽可能多地画图
。
回想一下,您第一次画立体几何图形的时候的场景。您当时是第一次就可以画出非常标准的立体几何图形吗?想要画好图,就要先多动手画图。
回顾 画图 —— 程序员必备的神技 一文中提到的 In-App Purchase 的大致过程,如果让您用文字、甚至单凭记忆来分析整个过程,您如何确保自己的分析是正确、清晰的?
人脑已经不够用的时候,可以用画图来帮助缕清楚思路。回想一下,您起初是如何理解递归过程的?面对复杂的递归算法,您如何有效地帮助大脑减轻工作量?
在一个方案落地之后,也许参与该方案的人会比较清楚整个过程。然而,随后参与进来的人员可能无法快速理解整个方案,尤其是复杂的方案。这时候,只需要配一张大体的流程图就可以帮助所有人快速缕清楚方案的整体思路。而且,绘制方案刘流程图的过程中,绘制者也能进一步加深对于改方案的理解,甚至可能找到方案的其他潜在问题。
一张图可以非常清晰地解释长篇大作要讲的内容。而且,大多数人不愿意去读那些长篇大作。
Ficow 发现,每个图都大致具有以下特征:
以下面的这个 UML 类图为例:
它的主题可以是:以 Person 类为核心的 UML 类图;如果一个图中的元素不具备明显的统一特征,那么给这个图一个易懂的主题名称,可以帮助别人迅速理解这个图想要表达的内容(如:xxx项目架构图、xxx方案流程图等);
不同的图形元素有:表示类的框体、表示继承关系的实线和三角形箭头;
不同的标注颜色:如果我们想突出显示基类,可以为基类的框体加上颜色,然后附上文字说明该颜色的含义;
必要的文字描述:Person 类和 Address 类之间的箭头线上标注了 0..1
, lives at
和 1
,用以说明单向的关联关系
。即:一个人可以住在某一个地址,一个地址归属于0或者1个人。
必要的图例:因为 UML 本身具有标准
,所以本图不需要附加图例。如果是自定义的草图,通常有必要用图例来说明图中的各种元素的含义。否则,其他人可能需要自行推测图中的内容。
很多朋友在开始学习画图的时候,都会习惯性地寻找工具软件。然而,Ficow 建议您先进行手绘。
这是 Ficow 建议您进行手绘的理由:
熟悉绘制的内容和规范
;关注需要绘制的内容
,而不是工具的使用;工具软件的限制
(如:付费版软件才有某些图形、软件不支持某功能);绘图工具软件可以让您画出来的图看起来更好看,但前提条件是您的图可以清晰地表达您想要表达的内容
Ficow 喜欢把绘图和会议
进行类比,这样可以很容易地掌握绘图的其他要点。
画图和会议都需要主题。主题可以帮助界定内容的中心
以及边界
。
试想一下,如果开会的时候没有议题,大家想聊什么就聊什么,会议会变成什么样?
同理,如果您只想展示数据库与数据库封装类的交互过程,那么绘制程序的启动过程就是多余的。
只绘制需要关注的内容,尽可能地精简图中的元素,这样可以帮助他人更高效地理解图里的信息。
和会议需要邀请与会者
类似,图中的元素也是您需要确定的。
开会前,我们需要邀请与会者,而这取决于他们在会议中将发挥怎样的作用。
同理,在画图的时候我们需要用不同的元素来发挥不同的作用。
图中除了方框、三角形,还有其他的图形吗?除了实线、虚线,还有其他线吗?
这些元素各自代表了什么含义?
最重要的是,其他人都能理解这些元素的含义吗?
如果某个图需要借助他人的口述或者大量的注释才能被人理解,那么这样的图宁可不画。
请看下面这个草图,然后尝试理解其中的内容:
请问,您能理解这个图想表达的内容吗?您能猜到这个图的主题吗?
如果要对它进行优化,我们可以做些什么?
首先,我们需要确定最想要表达的内容。比如:用户从登录到获取 WeddingWebsite 数据的流程
。
然后,去除无关的因素(track event, save to file 等):
接下来,我们要统一图中的元素: 通过观察我们可以发现这个图中的 login 是个动词,token, UserInfo 等都是名词。
一种较为合理的做法是 将结点定义为名词,结点要代表发起动作的实体;将发起的动作标注到箭头线上,箭头从调用方指向被调用方(主动的实体指向被动的实体)
。
调整后的效果如下图所示,仅供您参考:
也许您心中想要的结果和该图不太一样,这完全是可以理解的。毕竟,这只是一个示例,并不是基于实际项目构建的。Ficow 只希望它能够给您带来些许启发。
通过观察可以发现,上图中已经出现了两种不同的框、两种不同的箭头线
。这时候,您可能会开始猜测甚至归纳总结不同的框和箭头线的含义
。
然而,图的作者(比如:Ficow)没有明确注明这些框和箭头线的含义。所以,对于这个图,每个人可能会有不同的理解。
这时候,为该图添加图例
就是必不可少的步骤。
此时,该图已经具备了主题、元素、图例
,并且去除了不相干的内容
。
然而,这个图展示的流程其实非常简单。如果我们需要展示调用的顺序,那就需要在图中标注解释调用顺序的元素,并且在图例中说明该元素的含义。
如果需要绘制的内容比较复杂,Ficow 建议您不要使用草图,而是采用 UML 中的活动图或者时序图。毕竟,UML 具有统一的规范,其拥有一般的草图无法比拟的优势。文末附有一些 UML 教程的链接,希望对您有帮助。
绘图不光是个脑力活,同时它还是个体力活。
除了要思考主题、元素之外,我们还要进行手绘或者利用工具进行绘制。在绘制的过程中,还免不了要进行多次的调整。
只要愿意多想、多练,我相信您一定可以提高自己的绘图技能。希望本文对您有所帮助~
最后,如果您有任何疑问,欢迎您给 Ficow 留言喔!
参考内容:
UML Basics
UML Class Diagram Relationships Explained with Examples
觉得不错?点个赞呗~
本文链接:何时画图?画什么图?如何画图?—— 画图前需要思考的问题
转载声明:本站文章如无特别说明,皆为原创。转载请注明:Ficow Shen's Blog