buguge - Keep it simple,stupid

知识就是力量,但更重要的,是运用知识的能力why buguge?

导航

IPSF—IpsfStateEnum 为何物?我为什么推荐IpsfStateEnum

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

 

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

IpsfStateEnum就好理解了。enum IpsfStateEnum { INIT, PROCESSING, SUCCESS, FAIL }

当一条数据的业务流转处在IPSF这4个状态中时,可以考虑直接用这个枚举。尤其是对于我们业务错综复杂的企业应用系统,这一点很重要。为什么这么说呢?

  • 曾经在一个周末,因运营要求,我和小王同学要修改 levy_payment_flow表的一条流水的状态为失败。王杰写了update语句并提交sql工单。运维执行后,我们发现数据竟然不对。原来,状态值改错了,不是FAIL,而是PAY_FAIL。相信其他同学在手动修改状态的时候,也会先行翻代码或字段注释,也许也碰到过如此往复的不堪经历。
  • 我们的数据表,尤其是zhongtai-channel系统里的表,每张数据表都有数据流转状态,程序里定义有与之对应的状态枚举。尽管我们要求开发人员为每个字段添加注释,但是,依然有些表字段的注释不完整,这就包括数据流转状态status字段。例如:`verify_status` VARCHAR(32) COMMENT '初始待核验/核验中/核验成功/核验失败'。 再例如:`separate_status` VARCHAR(32) COMMENT '分账状态,SeparateStatusEnum'
  • anyway,同样表示失败,一些数据状态命名为FAIL,一些数据状态命名为FAILED,一些数据状态命名为FAILURE,一些数据状态还加个前缀如PAY_FAILED / PAY_FAIL,千人千面,这太考验人的记忆力了。
  • 待结算、待支付、待分账、数据待同步、待提现,待核验、待认证,这些各种“待”都可以抽象成INIT;结算中、支付处理中、分账中、数据同步中、提现中、核验中、认证中,这些各种ING都可以抽象成处理中-Processing。

基于以上,是否可以佐证当一条数据的业务流转处在IPSF这4个状态中时,可以考虑直接用这个IpsfStateEnum枚举呢?

答案我想是肯定的。

当然Ⅰ,能不能用需要基于对业务流转的全面了解,以及对短期业务流程变化的预判。例如zhongtai-channel的各种流水表,大都适合IpsfStateEnum。相较于业务系统的业务单据数据,往往不仅限于这4个状态,那就不要考虑IpsfStateEnum了。

当然Ⅱ,事物是发展变化的。有些数据的流转状态可能会永远定格在IPSF这4个,而有些数据的状态在未来或某些时期可能会有新增,例如:levy_payment_flow曾经就出现过“部分结算成功”的case。这时,我们所要做的,不是扩充IpsfStateEnum,而是新定义一个枚举,来满足levy_payment_flow的数据状态,例如 LevyPaymentFlowStatusEnum {INIT, PROCESSING, SUCCESS, FAIL, PARTIAL_SUCCESS }。这样一来,我们无需修改任何数据,只需变更entity以及dto里状态field的枚举类型即可。

当然Ⅲ,如果数据状态没有I/P,只有S/F,这种情况,你用IpsfStateEnum并不会增加什么理解成本。当然,不想用IpsfStateEnum的话,你单独定义的枚举里,S/F的命名也要与IpsfStateEnum里S/F的命名一致。也就是说,IpsfStateEnum固然是无法满足所有数据的状态流转,不过,我们完全可以约束:无论什么数据的流转,成功或完成都使用Success表示、失败都使用Fail表示,处理中都使用Processing表示。

综上,推荐使用IPSF其实是出于企业应用系统要尽可能统一数据词典,使用一致的术语和定义,以确保在不同开发组和系统之间进行沟通和协作时的一致性。正如上面所提到的,同样表示成功状态或失败状态,如果都定义不一样的名字,这对于系统的维护会带来许多麻烦。企业应用中,类似案例有许多,例如product、goods、commodity都可以商品,merchant、enterprise甚至company都可以表示企业客户,如果大家各行其是,这样的系统势必将会十分混乱。多数程序员缺乏英语词汇的积累和理解,通常依靠翻译工具来进行变量、类、服务的命名。如果没有通过统一的数据词典加以规范约束(规约),那么,同样表示企业客户,就会出现merchant、enterprise、company,以及其他五花八门的命名。

 

 

 

附:插图素材来自我的processOn

扩展阅读:当pageIndex遇上pageNo

▋ no 搬运,no copy。一段一文皆源于自己的深度思考,并在项目实践中打磨和沉淀。您的阅读就是最大的支持,感觉有用就请点击下方 5cm 处右侧的“推荐”,给我继续创作的源动力!

posted on 2023-10-19 09:00  buguge  阅读(48)  评论(1编辑  收藏  举报