前言

ladybug-flow專案從釋出第一版開源到今天已經過了2個多月，

釋出了11個小版本，得到7顆星（包括自己給自己的一顆星）。

雖說戰績很一般，但對於剛接觸開源的我來說已經很滿足了。

遂寫此文章來紀念一下。

 

初心

之前的文章寫過，此專案最早來自於一個公司的一個小小的需求，做一個AI專案時，有好多Job需要進行編排，

要求通過資料庫設定對Job進行並行，Join的編排，簡單的調查後發現上一個工作流太重，SpringBatch對JobFlow的處理又不靈活。

遂自己寫了一個簡單的框架完成了此任務。

當時只是簡單的存入Job的先後關係，用Future來監控Job的完成狀態，從而達到按指定順序啟動Job並且對順序可設定的目的。

隨後深感SpringBatch對Job的Flow這塊的支援是一大弱點，流程設定及其重，並且不支援視覺化。

於是決定寫一個輕量級的工作流框架，能進行流程視覺化，又可以通過引入Jar包的方式簡單的呼叫。

所以有了此專案ladybug-flow

拖拽一個流程，生成json，繫結流程節點與Java方法，即可完成對Flow的執行和監控。

 

難處

完成了初版後，釋出到github和maven倉庫裡，當maven倉庫釋出完成的那一刻，自己還是滿有成就感的。

以為到此即完成了整個專案的一大半，誰知千里執行始於足下，接下來的一系列現實讓我深深的認識到，

我以為的完成了一大半60%，實際上還沒有完成1%。

設計和寫程式碼以外的工作量和難度遠遠超過了專案本身。

 

難處1：寫Readme

專案本身有很多功能點，都寫到Readme裡對我來說顯然是一個龐大的工程，

於是摘取哪些要點，寫到哪種程度的Readme，對於我這個理科生來說簡直是無從下手。

最終在google了各種Readme技巧後，勉強算是寫完了一版Readme。

 

難處2：寫文章

這個不多說，相信看到這裡的同學對此都深有體會，

和給程式碼寫註釋一樣的是，寫文章的時間遠遠超過寫程式碼的時間。

和給程式碼寫註釋不一樣的是，不能瞎寫，簡寫。要寫的讓大家看明白，還要注意篇幅，格式等。

 

難處3：Star

對於剛開源的專案，又屬於小眾群體的專案，每一個Star都能讓我激動的徹夜難眠。

想過讓熟人給Star，也想過那個啥，但最終覺得這些都比不上來自陌生人對專案的認可。

於是，沒有讓熟人知道自己的專案，也沒有花錢那個啥，決定體驗每一個Star給自己帶來的快樂。

感謝大家的Star！

ladybug-flow:

ladybug-flow-ui:

 

難處4：對於專案方向的把握

在公司的客製化專案是需求驅動開發。

開源專案初期正好相反，通過開發出一些功能來擠出新的需求。

所以對於方向的把握尤其重要，最開始以為的方向，經過幾輪反饋後，往往最終會產生很大的偏差，

於是，收集使用者的反饋，需求，最終是專案朝著一個方向前進，這個實際操作起來是相當有難度的。

 

回顧

讓你的流程圖"Run"起來

。。。

首先要有一個繪製流程圖的介面。並且能夠將流程圖轉化為json格式。
這裡我選擇了Vis.js的network。
可以編輯簡單流程，如下

還可以實現流程圖和json之間的互轉。

我們把這些節點的基本資訊拿到，就可以得到一張圖，然後通過程式遍歷這張圖的每個節點，即可達到執行流程圖的效果。

。。。

感謝大家對我的支援！

 

以後

ladybug-flow會朝著輕量級工作流的方向越走越遠。

希望大家長期關注專案

最近為專案加了UI監控介面，張這個樣子：

原始碼：

https://github.com/nobuglady/ladybugflow

https://github.com/nobuglady/ladybugflow-ui