来源：https://www.cnblogs.com/duck-and-duck/p/14436373.html
第1关
一天，老板找到我，说要做个简单的工作流引擎。
我查了一天啥是工作流，然后做出了如下版本：
老板：简陋了点。
第2关
老板又来了：要支持会签节点。
我又查了一天啥是会签节点，发现会签节点就是一个大节点，里面有很多审批人，当这个大节点里的所有人都审批通过后，才能进入下一个节点。
我想了一个星期，推翻了原来的链表式设计：
结构上我做了如下调整:
-
把节点分为两大类：简单节点(上图中长方形)和复杂节点(上图中圆形)。
-
用一棵树表示整个流程，其中叶子节点都是简单节点，简单节点都是叶子节点。
-
每个简单节点里都有且仅有有一个审批人。
-
复杂节点包含若干个子节点。
-
加入会签节点: 会签节点激活后，所有的子节点都可以审批，当所有的子节点都审批完毕后，会签节点完成。
-
加入串行节点：子节点只能从左到右依次进行审批，当最后一个子节点审批完成后，串行节点完成。
-
所有的工作流最外层都是一个串行节点，该节点完成后代表整个工作流完成。
为了控制审批流程，我设计了一些节点状态:
-
Ready : 可以进行审批操作的简单节点是Ready状态。
-
Complete : 已经审批完成的节点状态。
-
Future: 现在还没有走到的节点状态。
-
Waiting : 只有复杂节点有该状态，表示在等待子节点审批。
借助上述规则，一次带会签节点的工作流审批过程如下：
老板：有点意思。
第3关
老板来了：要支持并行节点。
我查了一下午啥是并行节点，发现并行节点是一个包含很多审批人的大节点，这个大节点里任何一个人审批通过，则该节点就完成。
然后很快就加入了并行节点：
-
并行节点是一个复杂节点，该节点激活时，任何一个子节点都可以进行审批，且任何一个子节点是完成状态时，该节点完成。
加入新状态 Skip :
-
当一个并行节点的子节点状态为非( Ready , Waiting )时，其它兄弟节点及其子节点的状态被置为 Skip 。
举个栗子🌰：
老板：这个设计添加新节点还挺方便的。
第4关
老板又来了：节点要支持嵌套，比如会签节点里有个并行节点，并行节点里又有个复杂节点，要可以嵌套任意层的那种。
我：其实已经支持了~
老板：小伙子有点东西！
第5关
老板又来了：要支持条件节点。
工作流附带一个表单，要根据表单的内容确定下一步进入哪个分支。
经过几天的冥思苦想，我加入了条件节点：
老板：已阅。
第6关
老板又来了：审批人多加两种类型，比如可以从表单中选择下一个审批人，还有根据发起人不同选择不同的审批人。
经过一番考虑，我把简单节点分成了3类：
老板：嗯。
第7关
老板又来了：节点可以从前往后审批，那能不能从后往前驳回？
我: ……
首先实现了驳回到发起人的功能，相当于一切从头开始：
老板：你小子偷懒。
第8关
老板又来了：先实现驳回到上一个审批人吧。
驳回到上一个审批人其实是个很复杂的逻辑，因为工作流中的节点可以无限嵌套，所以如何确定上一个状态有哪些审批人并不简单。
牺牲了一些头发，我终于实现了驳回上一级的功能：
老板：阅。
第9关
老板又来了：实现一个驳回到任意节点的功能。
我发现这个需求并不难实现：
第10关
老板又来了：在普通节点加一个时间限制，要是在规定时间内没完成就显示已超时。
我：还有这种需求?
不过还是实现了。
此时我明白了需求和头发呈负相关，需求越多，头发越少。
第11关
老板又来了：加一个代理功能，比如有件事让你审批，但是你拿不准，那就转给拿得准的人审批。
马上我发现这个需求跟以往有本质的不同，以往的工作流的节点关系一开始就是固定的，就是在发起流程之前确定的，但是现在要在审批过程中更改。
无非是加了一些班，掉了一些头发，最终设计了如下方案：
第12关
老板又来了：能不能再加一个取消代理的功能？
