关于java:老板要我开发一个简单的工作流15-次需求变更我干到秃了

39次阅读

共计 2679 个字符,预计需要花费 7 分钟才能阅读完成。

第 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,身心健康,攒的钱够在一线城市买两套房,在若干年后能无病无灾的过上领养老金的休闲退休生存。
近期热文举荐:

1.600+ 道 Java 面试题及答案整顿(2021 最新版)

2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了,真香!

3. 阿里 Mock 工具正式开源,干掉市面上所有 Mock 工具!

4.Spring Cloud 2020.0.0 正式公布,全新颠覆性版本!

5.《Java 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

正文完
 0