開源兩個月總結
- 2022 年 9 月 6 日
- 筆記
前言
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監控介面，張這個樣子：
源碼：
//github.com/nobuglady/ladybugflow
//github.com/nobuglady/ladybugflow-ui
