老闆要我開發一個簡單的工作流引擎

MCTW發表於2021-03-03

第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,身心健康,攢的錢夠在一線城市買兩套房,在若干年後能無病無災的過上領養老金的休閒退休生活。

 

相關文章