通用工具_程序员画图技巧与样例
1.前言
作为一个程序员，当我们在进行方案设计、架构review、晋升答辩等场景，给别人讲解我们项目时，要让别人快速看懂和理解我们的流程、架构时，一定不能通过直白的文字来介绍，没有人乐意去看直白的文字然后自己去脑海中凭空构建架构。我们一定要画好架构图、流程图等图为主，再以简练的文字为辅，最后在必要时加上详细的文字说明，确保别人能够通过图和简练文字就大致明白你要表达的逻辑。
2.画图要点
简单专注
画图尽量简单专注，选好要讨论的层次，一般一张图最多涉及3-4层。大而全的图一般画不清楚，也看不清楚。读者思维，根据待讨论的问题画图。
颜色的用途
颜色使用没有统一的规定，可以根据具体的情况灵活使用。可以用来区分状态，也可以用来区分领域、模块等。如果图中使用了颜色的话，比较好的做法是在某个角落增加颜色说明（如 灰色代表功能未实现等）。
颜色的数量
一张图片中的颜色不宜过多，一般最多不超过3个。颜色过多可能会导致看起来不专业，同时也会让看图的人抓不到重点。如果画图的时候发现要用到很多颜色，可能是把不同层次的问题放到了一张图里，可以根据看图的人确定要讨论的问题然后突出重点。
画里的关系
并不是所有的关系都需要在图里表现，一般只需要表现出重要的关系。有时候系统里的调用关系复杂，全画出来只会让人看的云里雾里抓不到重点。
关系的表现
表现关系的形式有很多，最明显的是在多个角色之间连线，一般连线上要写上文字说明，方便理解，带不带箭头根据实际情况判断。如果关系是简单的关系如并列关系、构成关系等，可以不需要连线，直接用方框的位置来表达。
复杂的关系
如果系统比较复杂，包含的角色特别多关系也特别复杂，可以把角色和关系分开画。有时描述角色的图为了展示系统全貌会加入很多角色，部分角色的关系其实对于本次讨论没有太大的影响。此时可以单独画一张描述关系的图，在图中更加专注核心的角色。
炫酷的图标
有些图画的非常美观，有很多图标。但是大部分情况下，我们用线框图也可以表达出同样的意思。有些图标获取成本比较低且很常用（如服务器、数据库等都是画图工具自带的），用一下也是极好的。
3.常见法则与样例
3.1 自身案例
我自己的博客京东商智_基于ClickHouse预计算&智能物化预计算&日志解析&ck2hbase组件技术方案也有不少图当时是花了不少心思画的，包括一些泳道图、流程图啥的，也可以借鉴借鉴。
流程图
泳道图
分类图
3.2 4R架构
顶层结构Rank：表示软件架构的分层。
组成角色Role：表示软件系统包含哪些角色。
角色关系Relation：表示软件系统角色之间的关系。
运作规则Rule：表示软件系统之间的角色如何写作完成系统功能。
Rank
Rank指软件架构是分层的，是自上而下逐层细化的。大部分情况下，我们在讨论或画架构图的时候会针对某一层展开，最多涉及到3-4层，但是一定不要试图把每一层都搅合在一起进行讨论或画图。做架构的时候可以自上而下思考，在确定顶层之后逐层细化拆解，一般不要超过5层。下图是微信架构的例子。
Role
Role指在软件系统中的角色。角色就是每一层架构的组成部分，在每一层对应不同的内容，它可以是大的业务系统，也可以是小的能力、模块。
Relation
Relation指的是软件系统中各角色的关系。角色要放在一个层必然是存在某种关系的，或是相互合作为用户提供服务，或是数据上下游关系等。在讨论架构或画架构图的时候要能够清晰的定义这些关系。
Rule
Rule是指软件系统角色之间如何协作来完成系统功能。软件的目的是为用户提供服务，既然是提供服务则软件系统必然是运动的，这其中的运行逻辑就是规则。
3.3 4+1视图
“4+1”视图中的“4”，指的是：逻辑视图、开发视图、过程视图、物理视图，“1”指的是场景视图。
逻辑视图
从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能。
开发视图
又称为实现视图，显示的是源代码以及实际执行代码的组织结构。
处理视图
又称为过程视图，显示程序执行时并发的状态。
物理视图
展示软件到硬件的映射。
场景视图
架构的描述，即所做的各种决定，可以围绕着上述四个视图来组织，然后由一些用例 （use cases）或场景(scenarios)来说明，从而形成了第五个视图，也就是场景视图。
3.4 架构图分类
架构图分类
业务架构图
客户端&前端架构图
系统架构图
应用架构图
部署架构图
系统序列图
