第 1 关
一天，老板找到我，说要做个简略的工作流引擎。
我查了一天啥是工作流，而后做出了如下版本：
- 按程序增加任意个审批人组成一个链表，最初加一个完结节点
- 记录以后审批人，当审批完后，审批人向后挪动一位
- 当审批人对应完结节点时，流程完结
老板：简陋了点。
第 2 关
老板又来了：要反对会签节点。
我又查了一天啥是会签节点，发现会签节点就是一个大节点，外面有很多审批人，当这个大节点里的所有人都审批通过后，能力进入下一个节点。
我想了一个星期，颠覆了原来的链表式设计：
构造上我做了如下调整:
- 把节点分为两大类：简略节点 (上图中长方形) 和简单节点(上图中圆形)。
- 用一棵树示意整个流程，其中叶子节点都是简略节点，简略节点都是叶子节点。
- 每个简略节点里都有且仅有有一个审批人。
- 简单节点蕴含若干个子节点。
- 退出会签节点: 会签节点激活后，所有的子节点都能够审批，当所有的子节点都审批结束后，会签节点实现。
- 退出串行节点：子节点只能从左到右顺次进行审批，当最初一个子节点审批实现后，串行节点实现。
- 所有的工作流最外层都是一个串行节点，该节点实现后代表整个工作流实现。
为了管制审批流程，我设计了一些节点状态:
- Ready: 能够进行审批操作的简略节点是 Ready 状态。
- Complete: 曾经审批实现的节点状态。
- Future: 当初还没有走到的节点状态。
- Waiting: 只有简单节点有该状态，示意在期待子节点审批。
借助上述规定，一次带会签节点的工作流审批过程如下：
老板：有点意思。
第 3 关
老板来了：要反对并行节点。
我查了一下午啥是并行节点，发现并行节点是一个蕴含很多审批人的大节点，这个大节点里任何一个人审批通过，则该节点就实现。
而后很快就退出了并行节点：
- 并行节点是一个简单节点，该节点激活时，任何一个子节点都能够进行审批，且任何一个子节点是实现状态时，该节点实现。
退出新状态 Skip:
- 当一个并行节点的子节点状态为非 (Ready, Waiting) 时，其它兄弟节点及其子节点的状态被置为 Skip。
举个栗子🌰：
老板：这个设计增加新节点还挺不便的。
第 4 关
老板又来了：节点要反对嵌套，比方会签节点里有个并行节点，并行节点里又有个简单节点，要能够嵌套任意层的那种。
我：其实曾经反对了~
- 能有限扩大的树形构造能够反对任意简单流程。
老板：小伙子有点货色！
第 5 关
老板又来了：要反对条件节点。
工作流附带一个表单，要依据表单的内容确定下一步进入哪个分支。
通过几天的左思右想，我退出了条件节点：
- 条件节点相似并行节点，只不过只有满足条件的子节点能力进入接下来的审批。
老板：已阅。
第 6 关
老板又来了：审批人多加两种类型，比方能够从表单中抉择下一个审批人，还有依据发起人不同抉择不同的审批人。
通过一番思考，我把简略节点分成了 3 类：
- 第一种：审批人是写死的。
- 第二种：审批人从表单中读取。
- 第三种：依据发起人和一个映射函数，算出审批人。比方 get_主管 (“ 钱某 ”) 失去钱某的主管 李某。
老板：嗯。
第 7 关
老板又来了：节点能够从前往后审批，那能不能从后往前驳回？
我: ……
首先实现了驳回到发起人的性能，相当于所有从头开始：
只有 Ready 状态的节点有权力驳回。（就像只有 Ready 状态的节点有权力审批一样）
老板：你小子偷懒。
第 8 关
老板又来了：先实现驳回到上一个审批人吧。
驳回到上一个审批人其实是个很简单的逻辑，因为工作流中的节点能够有限嵌套，所以如何确定上一个状态有哪些审批人并不简略。
就义了一些头发，我终于实现了驳回上一级的性能：
老板：阅。
第 9 关
老板又来了：实现一个驳回到任意节点的性能。
我发现这个需要并不难实现：
- 一直的驳回上一级，直到 Ready 状态的节点蕴含要驳回到的节点为止。
老板：嗯。
第 10 关
老板又来了：在一般节点加一个工夫限度，要是在规定工夫内没实现就显示已超时。
我：还有这种需要?
不过还是实现了。
此时我明确了需要和头发呈负相关，需要越多，头发越少。
第 11 关
老板又来了：加一个代理性能，比方有件事让你审批，然而你拿不准，那就转给拿得准的人审批。
马上我发现这个需要跟以往有实质的不同，以往的工作流的节点关系一开始就是固定的，就是在发动流程之前确定的，
然而当初要在审批过程中更改。
无非是加了一些班，掉了一些头发，最终设计了如下计划：
- 代理操作的实质是，新建一个并行节点作为本节点的父节点，再新建一个兄弟节点放代理人，这样本人和代理人都能审批通过。
- 代理操作能够有限嵌套，即代理人也能够找人代理。
第 12 关
老板又来了：能不能再加一个勾销代理的性能？
。。。我曾经宠辱不惊了，加就加：
- 勾销代理是代理的逆操作
- 如果代理人审批过了那就不能取消代理
第 13 关
老板又来了：给每个节点加个前后置条件吧，满足前置条件能力进入该节点，满足后置条件该节点能力审批实现。
我的心田：啊老板再见，啊老板再见吧再见吧再见吧！
我的嘴：好的老板，收到收到。
起初：起初我真的给每个节点加了前后置条件，与此同时审批逻辑的相干代码减少了一倍。
第 14 关
老板又来了：当初有的工作流曾经非常复杂了，审批起来耗时较长，能不能对每个进行中的工作流计算一个指标：直观的显示目前审批进行的百分比。
我：收到。
其实跟之前的需要比起来这个并不简单，因为不波及外围逻辑的改变，实质只是输出一棵树形构造而后依据不同节点的状态输入一个整数。
通过测试思考，最终敲定的计划如下：
- 工作流实现的百分比指的是树中最右侧 Ready 状态的节点到最左侧节点的间隔 / 最右侧节点的间隔。
第 15 关
老板又来了：能不能给每个节点挂两个能够执行的脚本，别离在开始审批该节点和审批实现该节点后执行？
我：收.. 到。
起初我当然实现了这个性能，同时也发现正值壮年的我曾经秃了。
后记
老板是清华毕业的高才生，不然大略想不出这么多鬼斧神工的需要，起初老板把这一套工作流零碎卖给了广 * 证券等公司，我也去别的公司分道扬镳，当然那个时候我认为我还有前程。
开始做这个工作流的时候我刚刚本科毕业，起初从这家公司公司到职的时候看镜子曾经垂垂老矣。这曾经是 3 年前的事件了，当初回想起那些加班改工作流的日子，依然心惊。
起源：cnblogs.com/duck-and-duck/p/14436373.html