程序员还是要注重代码复用的

我这边的自研系统需要对接低代码平台日常做得最多的事情就是往低代码平台的表格里更新记录或者新增记录。看起来就两个操作但对接低代码平台的OpenAPI要处理的细节不少构造请求、设置参数、调用网关、解析响应。早期做对接的时候我把更新和新增这两个操作各封装了一个通用方法后面不管哪个业务场景需要同步数据到低代码平台调用方一两行代码就搞定了。这次从这两个方法出发来聊聊代码复用这件事。没做封装时的重复代码没有走通用方法的业务方法每个里面都在重复做同一套流程构造GatewayRequestDTO、设置configId、设置externalSystem、构造data map往里放worksheetId和triggerWorkflow开关、构造controls列表逐个add字段名值对、构造dataMap、设置requestBizData、构造requestHeaders、调用request方法、解析响应判断success。少则20行多则40行每个方法里这段代码长得几乎一样区别只在于更新哪些字段、更新什么值。GatewayRequestDTO request new GatewayRequestDTO(); request.setConfigId(configId); request.setExternalSystem(lowcode); // 构造controls、dataMap、requestBizData、requestHeaders... gatewayService.request(request);我们对接低代码的场景是非常多的不做封装就会有很多重复的代码每份20~40行。更麻烦的是如果低代码平台升级了API改了参数结构散落在10个方法里的对接代码全部要改一遍漏改一个就是线上故障。另外我接触过的但凡厉害一些的程序员都是非常注重复用和封装的且是刻到骨子里的那种。如果你一直以来都没有这样的意识那我觉得你得审视一下自己了。两个通用方法的设计两个通用方法分别对应更新和新增设计思路是一样的把低代码平台API中不变的部分封进方法内部把变化的部分抽取成参数。不变的部分构造GatewayRequestDTO的方式、设置externalSystem、构造请求头的逻辑、调用网关的方式、解析响应判断成功的逻辑。这些在每个业务方法里完全一样没有任何差异。变化的部分操作哪个表格、更新或新增哪些字段、属于哪个低代码应用、是否触发工作流、业务使用场景描述。这些因业务而异必须由调用方传入。其中最关键的设计决策是fieldName和fieldValue的抽象。低代码平台的表格字段是动态配置的不同业务场景关心的字段完全不同没法在编译期确定。用一个DTO把字段名和字段值配对调用方传一个List进来通用方法内部统一转成controls列表。public class LowCodeTableFieldDTO { public String fieldName; public String fieldValue; }调用方只需要告诉通用方法「我要更新哪些字段、每个字段的值是什么」不需要知道低代码API内部怎么组装controls参数。不同业务传不同数量的DTO进来就行更新一个字段传一个更新三个字段传三个方法签名不需要任何变化。LowCodeAppEnum用来约束应用标识的取值范围。低代码平台上会创建多个应用不同业务对应不同的应用用枚举避免调用方传错。文章里枚举值用A、B、C代替实际项目中对应不同的低代码应用。另外还有个使用场景参数传入一段业务描述字符串内部用于日志记录线上排查问题时能快速定位是哪个业务在调用。封装后的调用封装之后调用方不需要知道低代码平台API的任何细节只需要告诉通用方法「我要更新哪个表格的哪些字段」或者「我要往哪个表格新增一条记录」。更新一个字段的场景比如退货审核通过后同步审核状态lowCodeClient.updateLowCodeTableFieldValue(更新退货单审核状态, refundTable, bizId, LowCodeAppEnum.B, List.of(new LowCodeTableFieldDTO(refundStatus, 审核通过)));更新多个字段的场景比如配货单发货后同时同步发货状态和发货时间lowCodeClient.updateLowCodeTableFieldValue(配货单发货状态同步, pickingTable, rowId, LowCodeAppEnum.B, List.of(new LowCodeTableFieldDTO(orderStatus,已发货), new LowCodeTableFieldDTO(shippingTime,2024-01-15 10:30:00)));新增记录的场景比如仓库数据首次同步到低代码平台调用addLowCodeRow不需要传行ID返回值就是新增行的ID后续更新时拿这个ID去定位就行。这就是更新和新增分成两个方法的原因更新需要行ID来定位已有记录新增不需要新增要返回行ID给调用方更新不需要返回。以前每个业务方法20~40行重复代码现在调用方只关注业务本身一两行代码搞定。小结代码复用的价值不在于少写了几十行代码而在于划清了知识边界。封装updateLowCodeTableFieldValue和addLowCodeRow之后低代码平台API的细节请求怎么构造、参数怎么组装、响应怎么解析这些知识被收进了通用方法内部调用方完全不需要了解。当三个以上的方法共享同一套流程骨架构造请求、设置参数、调用接口、解析响应只是填充的数据不同这就是一个明确的信号应该提取通用方法了。这个判断标准比DRY原则更具体DRY告诉你要消除重复三个方法同骨架告诉你在哪里动手。日常开发中遇到这种情况停下来花几分钟做个封装后面每次用都省心维护成本也大幅降低。最近在知乎出了「应付6000万会员的秒杀系统专栏」「几亿用户,百万并发的C端商品系统实战」「技术团队DDD领域驱动设计三年落地实战」「应付亿级用户规模的支付系统代码实战」「应付亿级用户的会员体系代码实战」专栏感兴趣的可以订阅一下。至于知识星球的可以搜老码头的技术浮生录它是一个能实际帮你解决难题的星球。有问题的找知心的Sam哥支持无限次语音一对一解决你遇到的难题。「另外后续我新写的所有对外的付费专栏在星球内都是免费的且可以拿到所有源代码。」当前星球里免费看的专栏是「应付6000万会员的秒杀系统专栏」「几亿用户,百万并发的C端商品系统实战」「技术团队DDD领域驱动设计三年落地实战」「应付亿级用户规模的支付系统代码实战」「应付亿级用户的会员体系代码实战」知识星球内后续将推出20个付费专栏覆盖电商全链路选购线用户会员营销线中后台购物车服务营销系统订单系统商品服务用户系统支付系统菜单服务结算服务从前台选购到中后台结算星球成员全部免费后续新增也不额外收费。我的知乎账号:SamDeepThinking