学会理清系统核心的状态机，能少抠不少代码

凡是写过代码的小伙伴一定经历过接手的项目里业务核心一大堆状态位，MySQL里字段上的注释、程序里的枚举一大堆。但是状态的变更都是在什么时候发生的，状态间是怎么流转下去的可能组里的老大哥也不能完全把每个细节说清楚，让你自己看代码慢慢抠。那么本章我们要学的状态机--它对状态的管理和标记能在很大程度上缓解研发团队里这种尴尬的现状。

本篇文章我们来继续学习用UML做需求分析和技术评审时经常会用到的另一个流程分析利器 -- 状态机图，英文术语叫做State Machine Diagram，在中文资料里一般会把它翻译成状态机图或者是状态图，大家知道这俩是一个东西就行，没必要那么较真儿到底哪种称呼才对。

认识状态机图

我们先来快速看一下状态机图长什么样子。

怎么样，是不是跟我们上一节学到的活动图很像，但是又有点不一样呢？这张状态机图表示的是我们上一节在案例演示中的员工请假流程中“请假申请”这个“物件”的所有状态和相应的流转过程。

这里我们再把表达请假审批业务流程的活动图拿来对比一下：

乍一看上去，状态机图与活动图很类似，实际上这两种图分别对应于两种不同的分析角度和分析阶段。活动图可以说是流程分析的万能图，什么流程都可以用活动图来表达，也是我们刚接触到业务需求后会先用到的工具。

设想一下在接到一个业务需求后，我们要做的是不是先把整体流程捋出来？捋出来之后呢？如果流程中涉及到某个核心业务实体的状态变更，那么接下来我们最好从以下几个方面来分析它的状态：

• 它都有哪些状态？（对应数据表里的可能的状态枚举）
• 这些状态里谁是初始态、谁是中间态、谁是最终态 ？（思考用什么技术方案保证流程结束后保证业务实体处在最终态，而不是卡在中间态，减少人工处理BUG的场景）
• 这些状态在整个业务流程中的哪些时机发生转换的？（理清代码里都有哪些要Update状态的逻辑）

上面三个问题中，我都在括号标注了为什么要考虑这些的原因，那么有没有一种工具让我们在需求分析和技术方案时能把这些东西直观的表达出来，再指导我们开发实现的呢？状态机图就是UML这个工具箱里专门让我们用来做这个事情的，所以以后一旦我们想要分析流程是如何围绕着其业务核心实体的状态展开的，应该首选状态机图。

那么接下来本节就来从语法到案例讲解再到实践练习全面地学习状态机图，此外我们还会在课程后半部分给到两个企业级项目的状态机图给大家参考，大家一定不要错过。

从活动图转换到状态机图

我们上面说过，做需求分析或者技术方案时应该先捋出需求的整个大的流程，这个流程使用活动图来表达，回到上面展示了请假审批这个流程的活动图中，活动图是将流程分解成了一个一个的活动（步骤），通过活动的先后顺序来展示流程是怎么开展的；

相信大家都用自己公司的OA系统请过假，提交请假后会走一个审批流，根据你请假的天数和类别（年假、调休、婚假等）在这个流程里会由不同职能的同事对你提交的请假申请进行审批，但基本流程肯定是你的直线主管、隔级主管、业务VP来审批。

啥意思呢？就是你提交了请假后，你的组长要审批、审批完了后是管你组长的部门老大来批，如果请假的天数超过3天（假设）还得最终让负责你们的VP来批，如果你是技术就是CTO给你最后批，是业务运营就是COO给你最终审批。为啥这样呢？可能是不想让你休太长的假？......聊跑偏了，继续咱们的学习。

通过上面的分析我们大概能知道，“请假申请”这个业务实体大概会有这些状态：