写代码不只是撸起袖子就干，还要有设计图

对于大多数程序员而言，基本上都是 拿 到需求，在自己脑海里构思一下，然后就是撸起袖子上手就干。然后，在干的过程中会遇到各种各样一开始没有识别到的问题。也有可能当代码敲到一半，发现之前的思路有一个不可解决的问题，只能换另外一种解决方案。这个时候就面临需求延期，或者自己加班两种选择。

对于程序员而言，前期系统设计分析越到位，编码中遇到的问题就会越少。加班的机会也会大大降低，比较，过程可控了。然而，对于设计而言，程序员基本上都是停留在脑海的层面。更多的，一般都是通过流程图，对整个代码逻辑上进行一个设计分析。

最近，对自己之前写的模块进行回归分析，换一种角度去审视自己之前的代码。以一个旁观者的身份，去对之前的代码进行分析，并整理系统设计分析相关的文档，给团队日后作为参考。通过对系统进行分析，以及绘制相关图表才发现，系统设计分析文档是多重要。如果当时有系统设计文档，自己在编码过程中遇到的问题都能够提前识别到。

系统设计分析分以下几个方面:

1、识别关联的系统。要确定当前需求中有哪些系统参与

2、识别不同的对象角色。不同对象角色有不同的操作内容

3、分析业务状态变更。对于复杂业务状态的变更进行分析

4、分析业务流程

以上几个方面如果都能够厘清，那么对于业务需求而言，就已经很不错了。系统设计分析可以使用UML下面几种图进行分析:

1、用例图

用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做。使用用例图，可以整理出当前的需求的场景是什么?哪些角色在使用?每个角色会使用哪些功能?

2、时序图

时序图通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它可以表示用例的行为顺序，当执行一个用例行为时，其中的每条消息对应一个类操作或状态机中引起转换的触发事件。时序图可以整理需求需要关联哪些系统，模块，在哪个操作节点上需要操作哪个系统，模块。

3、状态图

描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。状态图，可以分析各个状态流转，确定哪些状态直接可以相互变更。比如，一个商品订单，有下单，付款，发货，确定收货，申请退款，退款中，退款完成。

4、活动图

活动图是阐明了业务用例实现的工作流程。业务工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。类似于流程图。可以用于分析业务流程。

在绘图的过程中，不必拘泥于UML的规则，只要图表表达含义正确即可。上面的图表作为工具，可以更加直观的展示业务系统，帮助程序员在当前需求 中 ，分析业务系统之间的关系，业务流转的时序，状态变更，业务操作流程。 有了上面的分析，相当于我们提前预演了一遍编码过程，可以很大程度上识别到编码中可能遇到哪些问题。

绘图是整理的过程，梳理出需求, 形成简单的文档;理出核心流程, 异常流程和状态,便于和团队其他人沟通快速上手业务逻辑。