“
一天，老板找到我，说要做个简单的工作流引擎，却成为我恶梦的开端...
No.1
第 1 关
我查了一天啥是工作流，然后做出了如上图版本：
- 按次序添加随便率性个审批人构成一个链表，最后加一个停止节点
- 记录当前审批人，当审批完后，审批人向后移动一位
- 当审批人对应停止节点时，流程停止
老板：简陋了点。
No.2
第 2 关
老板又来了：要支撑会签节点。
我又查了一天啥是会签节点，发明会签节点就是一个大年夜节点，里面有很多审批人，当这个大年夜节点里的所有人都审批经由过程后，才能进入下一个节点。
我想了一个礼拜，颠覆了本来的链表式设计：
构造上我做了如下调剂：
- 把节点分为两大年夜类： 简单节点（上图中长方形 ） 和复杂节点（上图中圆形 ） 。
- 用一棵树表示全部流程，个中叶子节点都是简单节点，简单节点都是叶子节点。
- 每个简单节点里都有且仅有有一个审批人。
- 复杂节点包含若干个子节点。
- 参加会签节点：会签节点激活后，所有的子节点都可以审批，当所有的子节点都审批完毕后，会签节点完成。
- 参加串行节点：子节点只能从左到右依次进行审批，当最后一个子节点审批完成后，串行节点完成。
- 所有的工作流最外层都是一个串行节点，该节点完成后代表全部工作流完成。
为了控制审批流程，我设计了一些节点状况：
- Ready： 可以进行审批操作的简单节点是 Ready 状况。
- Complete： 已经审批完成的节点状况。
- Future： 如今还没有走到的节点状况。
- Waiting： 只有复杂节点有该状况，表示在等待子节点审批。
借助上述规矩，一次带会签节点的工作流审批过程如下：
老板：有点意思。
No.3
第 3 关
老板来了：要支撑并行节点。
我查了一下昼啥是并行节点，发明并行节点是一个包含很多审批人的大年夜节点，这个大年夜节点里任何一小我审批经由过程，则该节点就完成。
然后很快就参加了并行节点：并行节点是一个复杂节点，该节点激活时，任何一个子节点都可以进行审批，且任何一个子节点是完成状况时，该节点完成。
参加新状况 Skip：当一个并行节点的子节点状况为非（Ready, Waiting ）时，其它兄弟节点及其子节点的状况被置为 Skip。
举个栗子：
老板：这个设计添加新节点还挺便利的。
No.4
第 4 关
老板又来了：节点要支撑嵌套，比如会签节点里有个并行节点，并行节点里又有个复杂节点，要可以嵌套随便率性层的那种。
我：其实已经支撑了~
能无穷扩大的树形构造可以支撑随便率性复杂流程。
老板：小伙子有点器械！
No.5
第 5 关
老板又来了：要支撑前提节点。
工作流附带一个表单，要根据表单的内容肯定下一步进入哪个分支。
经由几天的冥思苦想，我参加了前提节点：前提节点类似并行节点，只不过只有知足前提的子节点才能进入接下来的审批。
老板：已阅。
No.6
第 6 关
老板又来了：审批人多加两种类型，比如可以从表单中选择下一个审批人，还有根据提议人不合选择不合的审批人。
经由一番推敲，我把简单节点分成了 3 类：
- 第一种：审批人是写逝世的。
- 第二种：审批人从表单中读取。
- 第三种：根据提议人和一个映射函数，算出审批人。比如 get_主管("钱某") 获得钱某的主管 李某。
老板：嗯。
No.7
第 7 关
老板又来了：节点可以早年往后审批，那能不克不及从后往前驳回？
我：......
起首实现了驳回到提议人的功能，相当于一切从头开端：只有 Ready 状况的节点有权力驳回。（就像只有 Ready 状况的节点有权力审批一样）
老板：你小子偷懒。
No.8
第 8 关
老板又来了：先实现驳回到上一个审批人吧。
驳回到上一个审批人其实是个很复杂的逻辑，因为工作流中的节点可以无穷嵌套，所以若何肯定上一个状况有哪些审批人并不简单。
就义了一些头发，我终于实现了驳回上一级的功能：
老板：阅。
No.9
第 9 关
老板又来了：实现一个驳回到随便率性节点的功能。
我发明这个需求并不难实现：赓续的驳回上一级，直到 Ready 状况的节点包含要驳回到的节点为止。
老板：嗯。
No.10
第 10 关
老板又来了：在通俗节点加一个时光限制，如果在规准时光内没完成就显示已超时。
我：还有这种需求？
不过照样实现了。
此时我明白了需乞降头发呈负相干，需求越多，头发越少。
No.11
第 11 关
老板又来了：加一个代理功能，比如有件事让你审批，然则你拿不准，那就转给拿得准的人审批。
立时我发明这个需求跟以往有本质的不合，以往的工作流的节点关系一开端就是固定的，就是在提议流程之前肯定的，然则如今要在审批过程中更改。
无非是加了一些班，掉落了一些头发，最终设计了如下筹划：
- 代理操作的本质是，新建一个并行节点作为本节点的父节点，再新建一个兄弟节点放代理人，如许本身和代理人都能审批经由过程。
- 代理操作可以无穷嵌套，即代理人也可以找人代理。
No.12
第 12 关
老板又来了：能不克不及再加一个撤消代理的功能？
......
我已经宠辱不惊了，加就加：
- 撤消代理是代理的逆操作
- 假如代理人审批过了那就不克不及撤消代理
No.13
第 13 关
老板又来了：给每个节点加个前后置前提吧，知足前置前提才能进入该节点，知足后置前提该节点才能审批完成。
我的心坎：啊老板再会，啊老板再会吧再会吧再会吧！
我的嘴：好的老板，收到收到。
后来：后来我真的给每个节点加了前后置前提，与此同时审批逻辑的相干代码增长了一倍。
No.14
第 14 关
老板又来了：如今有的工作流已经异常复杂了，审批起来耗时较长，能不克不及对每个进行中的工作流计算一个指标：直不雅的显示今朝审批进行的百分比。
我：收到。
其实跟之前的需求比起来这个并不复杂，因为不涉及核心逻辑的修改，本质只是输入一棵树形构造然后根据不合节点的状况输出一个整数。
经由测试思虑，最终敲定的筹划如下：工作流完成的百分比指的是树中最右侧 Ready 状况的节点到最左侧节点的距离 / 最右侧节点的距离。
No.15
第 15 关
老板又来了：能不克不及给每个节点挂两个可以履行的脚本，分别在开端审批该节点和审批完成该节点后履行？
我：收..到。
后来我当然实现了这个功能，同时也发明正值丁壮的我已经秃了。
No.16
跋文
老板是清华卒业的高才生，不然大年夜概想不出这么多鬼斧神工的需求，后来老板把这一套工作流体系卖给了广*证券等公司，我也去其余公司各奔前程，当然那个时刻我认为我还有前程。
开端做这个工作流的时刻我方才本科卒业，后来从这家公司公司离职的时刻看镜子已经逐渐老矣。
这已经是 3 年前的工作了，如今回想起那些加班改工作流的日子，仍然心惊。
最后愿世界的同业们都没有 Bug，身心健康，攒的钱够在一线城市买两套房，在若干年后能无病无灾的过上领养老金的休闲退休生活。
作者：MCTW
编辑：陶家龙
