背景：

在参与完成上海供销社，青岛中台，新疆国资委等国资委上报场景的开发或者维护过程中看到的重复性，不一致性以及能可拓展性的理解，接下来将会以实际项目中出现的情况，可修改的地方，以及修改可能导致的问题三个维度进行整理进行整理说明，对应的代码和截图不会进行展示，以下整理旨在减少后端人员维护，解放后端工作人员去处理其他项目

1.相同接口逻辑下不同国资委的重复接口开发—可抽离共性

1.1 河南国资委，上海国资委在项目中出现的实际情况

首先是河南国资委与上海国资委的账户信息相关的内容，账户信息和账户余额两个场景，上海国资委一开始的组装数据逻辑是基本照搬河南国资委的逻辑，成功报送了国资委(仅仅几天，我会在下文详细说明)

1.2 可修改之处

该部分的逻辑完全可以再次策略一段，无需再次复制一份相同的逻辑的国资委上报逻辑，同时任意一方的质量问题修改都能同步到另一方，减少维护的成本

比如在上海国资委照搬河南省国资委的逻辑之后，曾出现相同流水号不能出现在同一天，总行映射方法逻辑错误，交易金额不能为负数的情况，这些场景我对河南省的账户数据和明细修改进行整理，看到了相同的问题，只能说河南省国资委方面对于这些内容核验程度没有上海国资委这么大

1.3 修改可能导致的问题

改内容的修改需要人员整理好接口文档信息，首先是找到共同共享的国资委接口文档，另外是不同国资委的映射编码是不一样的，贸然抽离再次策略一层会让这些映射编码的控制变得十分困难，到时代码将会十分复制，反倒不如现在的体系，否则将会是更加复杂的策略和模板设计

2.补报逻辑的支持

2.1网络波动或者说是连接不良导致的上报情况

该部分情况出现情况很少，但是一旦出现，对于现在的体系下想要补报信息，除非批次已经收集好了信息，否则就到更改数据库配置，该部分效率低下，又或者说部分客户的数据需要一整年进行报送，又或者说客户某一天的数据新增些内容需要重新发送，对于现在的操作来说都是十分复杂的

2.2预留补报逻辑的设计

该部分的设计我设想了两个模式，模式1是正对对应批次数据的重新归集报送，模式2为一段时间范围内的数据补报，但目前只有模式2能用并且只能是上海国资委使用并且是针对后端人员开发出来的，该部分的逻辑需要考虑代码中这么传入历史时间，怎么获取历史时间，一些国资委上报要求数据日期，但现在的数据日期除了上海国资委，其他国资委无法支持。另外查询条件也是一个问题，账户信息这些“时节点”归集没有问题，但是对于融资场景就是一个问题了，可能需要数据层面的支持

2.3可能导致的问题

暂时没看到会出现的问题在哪里

3.日志显示和数据检查

3.1上报失败不一定是代码问题

每日在群中都可以看到成功多少，失败了多少，失败的数据基本是用户没有填写必要信息，但目前我们的日志不能精准的指出问题，并且大家检查逻辑和日志都是各自为政，检查逻辑没有统一成一种方法，日志也只是显示一个主键id，或者是不直接指出问题，有时实施人员甚至不能找到缺少了什么信息，主键对于他们来说有什么用呢，最终还是得联系后端人员去查库，去看日志

3.2统一检查逻辑，注意日志内容

现在青岛中台和上海国资委采用的检查是比较完善的，出现了问题后端人员只需要看一次日志就能知道问题，但是还是不够，必须加以数据库字段支持，需要能记录下缺少字段信息，反显回前端，加以日志控制就可以实现类似合同编号—错误信息，账户—错误信息，授信编号—错误信息这样的效果

想要实现这样的逻辑完全可以改造青岛中台的检查方法，稍微改造配合注释，就连新疆国资委这样比较特殊的组装也可以实现检查

3.3可能出现的问题

日志检查必须及时更新数据状态，对于不符合要求的数状态更新和我们获取数据的细节，这部分的坑已经在上海国资委和青岛中台踩全了，可以作为参考

4.重复代码和通用性

4.1额外查询的情况

这个是项目中出现的最简单的例子了，比如余额上报有时候需要查询账户信息，每个人员在国资委几乎都在自己写自己的额外查询逻辑，可是仔细看过去，逻辑完全是一样的，不加以注意的话就会出现新疆国资委我一直在检查的一个问题，额外查询的时候没有分页，这样维护旧代码就会十分效率低下，又或者说新人员维护的时候，对这个部分不理解的时候，就会在这里纠结很长一段时间，本身不是复杂的代码，何必为难很长的时间呢？

4.2统一逻辑，减少冗余代码

只需要额外查询回来东西就行，用现在归集逻辑的部分代码完全可以承接这个任务

4.3对已存在项目的影响

有些项目中归集数据只取其中一个指标进行返回，贸然修改会导致这些项目出现问题，体现在新疆国资委中

未完结，待后续更新