前言
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
标签：总结,ladybug,Star,项目,Job,开源,Readme,两个 From： https://www.cnblogs.com/nobuglady/p/16658919.html