本文摘自公司内部WIKI知识库
先看IPSF这4个字母分别代表什么？Init-Processing-Success-Fail
IpsfEnum就好理解了。enumIpsfEnum { I, P, S, F }
当一条数据的流转在上面4个状态中时，可以考虑直接用这个枚举。为什么？
- 曾经在一个周末，因运营需要，我和王杰同学要修改 levy_payment_flow表的一条流水的状态为失败。王杰编写好update后提交sql工单，运维执行。后来发现数据不对。 状态值改错了，不是FAIL，而是PAY_FAIL。相信其他同学在手动修改状态的时候，也会先行翻代码或字段注释，也许也碰到过如此往复的不堪经历。
- 我们的表，尤其是zhongtai-channel系统里的表，每个表都有数据状态，并定义有与之对应的状态枚举。尽管我们要求开发人员为每个字段添加注释，但是，依然有些表字段的注释不完整，这就包括status字段。例如：
`status` VARCHAR(32) COMMENT '初始/处理中/成功/失败'
status` VARCHAR(32) COMMENT '分账状态，SeparateStatusEnum'- anyway，同样表示失败，一些数据状态是FAIL，一些数据状态是FAILED，一些数据状态是FAILURE，一些数据状态还加个前缀如PAY_FAILED/PAY_FAIL，千人千面，这太考验人的记忆力了。
- 结算中、支付处理中、分账中、数据同步中、提现中，这些各种ING都可以抽象成处理中-Processing。
基于以上，是否可以佐证当一条数据的流转在上面4个状态中时，可以考虑直接用这个IpsfEnum枚举呢？
当然Ⅰ，能不能用要基于对业务流转的深刻了解，以及对短期变化的预判。例如channel的各种流水表，大都适合IpsfEnum。相较于业务系统的业务单据数据，往往不仅限于这4个状态，那就不要考虑IpsfEnum了。
当然Ⅱ，事情是发展变化的。有些数据的状态可能会永远定格在IPSF这4个，而有些数据的状态在未来或某些时期可能会有新增，例如：levy_payment_flow曾经就出现过“部分结算成功”的case。这时，我们所要做的，不是扩充IpsfEnum，而是新定义一个枚举，来满足levy_payment_flow的数据状态，例如 LevyPaymentFlowStatusEnum {I, P, S, F,PARTIAL_SUCCESS }。这样一来，我们无需修改任何数据，只需变更entity以及dto里状态field的枚举类型即可。
