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

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