[Golang]一个工单系统的重构过程-FP vs OOP

背景

组内的数据管理平台承担着公司在线特征数据的管理工作。开发通过提交工单接入我们的数据系统。工单模型在设计之初只考虑到了一种类型的工单(新特征的申请)，对于工单生命周期的每个节点分别用一个接口去实现。随着业务迭代，还有一些操作也需要通过走工单让管理员审批执行。此时最初的工单模型不能满足需求，此时为了让系统先用起来，我们的做法是写单独的接口去实现...这样虽然能用，但是导致后端代码里多出来了很多API。趁着过年前几天业务不多，我对工单部分代码进行了重构，希望达到的效果是后续不同类型的工单复用同一套工单流程，同时减轻前后端交互的成本。

需求分析

经过抽象，对于我们的系统不同类型的工单，工单的生命周期都是一样的，工单只有这些状态：

工单这几个状态要执行的操作差别是很大的，所以分别用不同接口去实现每一种工单状态，这其中代码的复用不多。工单状态和执行操作如下图：

前面说到，在系统之前的代码里面不同类型的工单分别用不同的API实现，看代码可以发现，不同类型的工单在生命周期的一个节点里面做的操作是类似的。比如对于新建工单，重构代码之前操作是这样：

增加工单种类之后，新建工单操作是这样：

其中校验前端参数、调用工单实例、发送通知的代码都是可以复用的。只有工单操作这一块行为有所区别，工单操作简单抽象一下分为两种：

实现思路

考虑到前端同学的开发成本，这次重构复用之前的接口，在每个接口参数里面增加一项工单类型(worksheetType)，根据工单类型，做不同的操作。

重构的思路有两种，一种是"函数式编程"(FP)，另一种是"面向对象编程"(OOP)。这里晒出一张经典的图片,hhh...

实现对比

为了对比两种方式，分别实现了demo。OOP如下：

FP如下：