老板要我开发一个简单的工作流,15 次需求变更,我干到秃了。。

简介: 一天,老板找到我,说要做个简单的工作流引擎。我查了一天啥是工作流,然后做出了如下版本:

一天,老板找到我,说要做个简单的工作流引擎。


我查了一天啥是工作流,然后做出了如下版本:


image.png


按顺序添加任意个审批人组成一个链表,最后加一个结束节点

记录当前审批人,当审批完后,审批人向后移动一位

当审批人对应结束节点时,流程结束

老板:简陋了点。


第2关

老板又来了:要支持会签节点。


我又查了一天啥是会签节点,发现会签节点就是一个大节点,里面有很多审批人,当这个大节点里的所有人都审批通过后,才能进入下一个节点。


我想了一个星期,推翻了原来的链表式设计:


image.png


结构上我做了如下调整:


把节点分为两大类:简单节点(上图中长方形)和复杂节点(上图中圆形)。

用一棵树表示整个流程,其中叶子节点都是简单节点,简单节点都是叶子节点。

每个简单节点里都有且仅有有一个审批人。

复杂节点包含若干个子节点。

加入会签节点: 会签节点激活后,所有的子节点都可以审批,当所有的子节点都审批完毕后,会签节点完成。

加入串行节点:子节点只能从左到右依次进行审批,当最后一个子节点审批完成后,串行节点完成。

所有的工作流最外层都是一个串行节点,该节点完成后代表整个工作流完成。

为了控制审批流程,我设计了一些节点状态:


Ready: 可以进行审批操作的简单节点是Ready状态。

Complete: 已经审批完成的节点状态。

Future: 现在还没有走到的节点状态。

Waiting: 只有复杂节点有该状态,表示在等待子节点审批。

借助上述规则,一次带会签节点的工作流审批过程如下:



image.png


老板:有点意思。


第3关

老板来了:要支持并行节点。


我查了一下午啥是并行节点,发现并行节点是一个包含很多审批人的大节点,这个大节点里任何一个人审批通过,则该节点就完成。


然后很快就加入了并行节点:


并行节点是一个复杂节点,该节点激活时,任何一个子节点都可以进行审批,且任何一个子节点是完成状态时,该节点完成。

加入新状态 Skip:


当一个并行节点的子节点状态为非(Ready, Waiting)时,其它兄弟节点及其子节点的状态被置为Skip。

举个栗子🌰:


image.png


老板:这个设计添加新节点还挺方便的。


第4关

老板又来了:节点要支持嵌套,比如会签节点里有个并行节点,并行节点里又有个复杂节点,要可以嵌套任意层的那种。


我:其实已经支持了~


image.png


能无限扩展的树形结构可以支持任意复杂流程。

老板:小伙子有点东西!


第5关

老板又来了:要支持条件节点。


工作流附带一个表单,要根据表单的内容确定下一步进入哪个分支。


经过几天的冥思苦想,我加入了条件节点:


条件节点类似并行节点,只不过只有满足条件的子节点才能进入接下来的审批。

image.png


老板:已阅。


第6关

老板又来了:审批人多加两种类型,比如可以从表单中选择下一个审批人,还有根据发起人不同选择不同的审批人。


经过一番考虑,我把简单节点分成了3类:


第一种:审批人是写死的。

第二种:审批人从表单中读取。

第三种:根据发起人和一个映射函数,算出审批人。比如 get_主管(“钱某”) 得到钱某的主管 李某。

image.png


老板:嗯。


第7关

老板又来了:节点可以从前往后审批,那能不能从后往前驳回?


我: …


首先实现了驳回到发起人的功能,相当于一切从头开始:


只有Ready状态的节点有权利驳回。(就像只有Ready状态的节点有权利审批一样)

image.png


老板:你小子偷懒。


第8关

老板又来了:先实现驳回到上一个审批人吧。


驳回到上一个审批人其实是个很复杂的逻辑,因为工作流中的节点可以无限嵌套,所以如何确定上一个状态有哪些审批人并不简单。


牺牲了一些头发,我终于实现了驳回上一级的功能:


image.png


老板:阅。


第9关

老板又来了:实现一个驳回到任意节点的功能。


我发现这个需求并不难实现:


不断的驳回上一级,直到Ready状态的节点包含要驳回到的节点为止。

老板:嗯。


第10关

老板又来了:在普通节点加一个时间限制,要是在规定时间内没完成就显示已超时。


我:还有这种需求?


不过还是实现了。


image.png


此时我明白了需求和头发呈负相关,需求越多,头发越少。


第11关

老板又来了:加一个代理功能,比如有件事让你审批,但是你拿不准,那就转给拿得准的人审批。


马上我发现这个需求跟以往有本质的不同,以往的工作流的节点关系一开始就是固定的,就是在发起流程之前确定的,


但是现在要在审批过程中更改。


无非是加了一些班,掉了一些头发,最终设计了如下方案:


代理操作的本质是,新建一个并行节点作为本节点的父节点,再新建一个兄弟节点放代理人,这样自己和代理人都能审批通过。

代理操作可以无限嵌套,即代理人也可以找人代理。

image.png


第12关

老板又来了:能不能再加一个取消代理的功能?


。。。我已经宠辱不惊了,加就加:


取消代理是代理的逆操作

如果代理人审批过了那就不能取消代理

image.png


第13关

老板又来了:给每个节点加个前后置条件吧,满足前置条件才能进入该节点,满足后置条件该节点才能审批完成。


我的内心:啊老板再见,啊老板再见吧再见吧再见吧!


我的嘴:好的老板,收到收到。


后来:后来我真的给每个节点加了前后置条件,与此同时审批逻辑的相关代码增加了一倍。


第14关

老板又来了:现在有的工作流已经非常复杂了,审批起来耗时较长,能不能对每个进行中的工作流计算一个指标:直观的显示目前审批进行的百分比。


我:收到。


其实跟之前的需求比起来这个并不复杂,因为不涉及核心逻辑的改动,本质只是输入一棵树形结构然后根据不同节点的状态输出一个整数。


经过测试思考,最终敲定的方案如下:


工作流完成的百分比指的是树中最右侧Ready状态的节点到最左侧节点的距离 / 最右侧节点的距离。

第15关

老板又来了:能不能给每个节点挂两个可以执行的脚本,分别在开始审批该节点和审批完成该节点后执行?


我:收…到。


后来我当然实现了这个功能,同时也发现正值壮年的我已经秃了。


后记

老板是清华毕业的高才生,不然大概想不出这么多巧夺天工的需求,后来老板把这一套工作流系统卖给了广*证券等公司,我也去别的公司各奔前程,当然那个时候我以为我还有前程。


开始做这个工作流的时候我刚刚本科毕业,后来从这家公司公司离职的时候看镜子已经垂垂老矣。这已经是3年前的事情了,现在回想起那些加班改工作流的日子,仍然心惊。


目录
打赏
0
0
0
0
308
分享
相关文章
运维小哥的工作自述
  光阴似箭,日月如梭!弹指间,回首想想,进公司的时间也不短了。在平凡的岗位上默默地耕耘着,似乎是那么不起眼~~但作为一颗螺丝钉,我要大声的告诉自己:螺丝钉也能有自己的价值体现!        于是乎,三省吾身!        几千号员工的上市企业,以总部和分部为个体划分,在个体中又以部门为单位划分,各部门的管理、财政、人事都实现独立。
2370 0
同事的一个动作,让我熬夜的工作全部白费…….
xtrlock 工具在大多数 Linux 发行版软件库里,我们可以直接使用对应的发行版的包管理器来安装它。 在 Debian,Ubuntu,Linux Mint上可直接使用 apt-get 命令安装
345 0
同事的一个动作,让我熬夜的工作全部白费…….
甲方怒喷半小时:一次项目上线失败的深刻教训
小米分享了一次项目上线失败的经历,起因是运营提出一个看似简单的白名单功能。问题包括:没有需求原型导致理解偏差,新成员对项目不熟悉,测试流程不全面,以及人员变动大。解决方案涉及需求确认会、原型图设计、交接制度、团队培训和全流程测试等。这次失败提供了关于需求分析、项目管理及团队协作的教训。
84 2
年度代码翻车现场 |前端代码评审问题总结
代码评审于技术团队的工程师文化建设非常有意义,它是形成团队统一代码风格最有效的方式,作者把自己团队在一年的CR中常见的那些小问题做了一些梳理,希望能对大家起到一点小帮助。
219939 7
前端代码评审问题总结年度代码翻车现场 |
团队已持续进行了一年多的线下周代码评审,作为主要评审人,我认识到虽然初衷是提供代码改进建议,但实际上大部分问题集中在基础代码质量上,而非设计或业务逻辑。因此,团队需保持耐心,逐步解决基础问题。本文总结了一年来常见的代码评审问题,如魔法值、eslint禁用、幽灵依赖等,并提出具体改进建议。此外,还强调了良好的代码习惯、命名规范及异常处理的重要性。通过持续代码评审,希望团队能在卓越工程的道路上不断进步。以下是常见问题的具体分析: ### 二、翻车现场(CR中的常见问题) #### 2.1 代码规范类 ##### 2.1.1 使用魔法值 - **危害**:代码不易读、不复用、易出错 - **建
46 3

热门文章

最新文章

相关实验场景

更多
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等