程序员的自我修养系列（四）：图形化表达

前言

对程序员来说，我们很多时候更专注于写代码，但是一个项目里代码只是整个交付的一部分，需求、设计、沟通很多时候比代码更重要，因为如果没搞清 "WHAT TO DO", 那么我们 "HOW TO DO" 是没有意义的。

根据我的经验，大部分程序员在沟通这块儿是需要提高的，而项目中很多问题，都是由沟通问题造成的，而这种问题的主要变现有多种，一种是我们不知道别人说什么，还有一种是别人不知道我们说的是什么。而文字很多时候是造成歧义的一个很重要的因素。

很多时候，我都推荐大家能用图形表达的，就不要用文字表达，原因如下：

厘清思路

帮助我们自己想清楚。如果我们想用图形表达，那么我们自己必须想清楚，不然图形就画不下去。

加速沟通反馈

图形是我们思想的一个简化模型的体现，可以去掉很多干扰信息，让我们快速理解，从而加快了沟通反馈速度

减少歧义

很多图形都是“通用语言”，就是已经在业界达成了共识，不用过多解释。

人脑更擅长理解图形

相对于文字，图像有画面感， 人脑更擅长记忆图像。

图像信息容量大

很多东西，如果我们用文字，需要几十页的描述，而用图可能一张纸就表达了，这给交流带来了极大的便利性。

程序员需要掌握的常用图形

我们知道不管是什么软件开发方法，传统瀑布，还是现在的敏捷开发，都离不开需求分析、设计、开发、测试等等。

而现在越来越强调 “全栈程序员” ，也就是很可能，你一个人要做一个项目，而且一杆子撸到底。所以我们必须掌握一些常用的图形表达工具。

在敏捷开发里，大家都用用户故事来表示需求，但是我总是觉得光用户故事感觉比较散，很难让人对整体有个了解，我觉得下面两种图，对表示系统功能很有帮助。

需求相关

用例图

用例图主要是从系统使用者的角度来描述每个角色可以使用哪些功能。

主要包括，角色(Actor)，功能(Use Case)，以及功能间是扩展关系(Extends) 还是包含关系(Includes)

功能结构图

功能结构图，可以清晰的表达，功能之间的分组，比如大的功能块下的小功能，通过这样分组，有的时候我们很容易把其中一个分支剪出来做一个子项目或者微服务。同时我们也可以根据不同的色块来标注功能的优先级。

脑图

有的时候，在早期阶段，我们主要收集需求的时候，脑图给我们带来了很多的灵活性，尤其是现在很多脑图软件，很方便的插入和修改。

设计相关

分层架构图

这是我们最常用到的，这种图形很简单，基本用方框和线条就可以了，主要表达层次关系以及相互依赖关系，大家经常见到的三层或者多层图就是这样的。

三层架构图

每层里面包含多个部分

包含通用组件，比如多个层里会用到的日志，异常模块等

跨层调用图

上面分层架构，一般都不会跨层调用，而现在有一些架构，比如领域驱动，整洁架构，六边形等等都可以跨层调用，这类架构都强调领域核心的概念，就是外层可以跨层调用内层，但一般内层不允许调用外层。基本上都是强调隔离出容易变化的文件，网络和外部依赖，以业务为核心。这类图，一般都是圆形图。

整洁架构

六边形架构

交互相关

系统之间交互图

这类图，一般表示不同子系统直接的交互关系，比如微服务

流程图

很多时候，我们想表达一些业务的流程，比如如果XXX，那么就YYY, 或者A完成就开始B，然后开始C等，那么流程图就是我们必须要掌握的

泳道图

主要用来表示不同角色或者不同组件之间的交互的顺序。

最后

我们需要的是要掌握的是用图来展示我们的想法，不要花太多时间让图很漂亮，比如色彩上。 大部分的图基本上都可以用笔可以很快在纸或者白板上画出来，或者Word一般就可以了。

当然，现在也有很多收费或者免费的软件，当你熟练了要表达的内容和结构后，使用这些软件就很容易。