老板要我开发一个简单的工做流引擎

第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年前的事情了，如今回想起那些加班改工做流的日子，仍然心惊。

最后愿天下的同行们都没有bug，身心健康，攒的钱够在一线城市买两套房，在若干年后能无病无灾的过上领养老金的休闲退休生活。