闯关之简单的工作流引擎

程序员 · 2024-10-3 17:48:43

第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关

老板又来了：能不能给每个节点挂两个可以执行的脚本，分别在开始审批该节点和审批完成该节点后执行？
小王：收..到。
厥后小王当然实现了这个功能，同时也发现正值壮年的小王已经秃了。

闯关之简单的工作流引擎

所属分类: 问答交流

新帖推荐: 30日

推荐作品