IPSF—IpsfEnum 为何物？我为什么推荐IpsfEnum

本文摘自公司内部WIKI知识库

先看IPSF这4个字母分别代表什么？Init-Processing-Success-Fail

IpsfEnum就好理解了。enum IpsfEnum { 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的枚举类型即可。