业务开发四大噩梦——不可靠的数据

这里说的不可靠的数据来源包括三个来源：请求参数、API返回、数据库。不可靠的数据在这里指的是没有按照约定赋值的数据。这个问题与无处不在的参数校验这个问题是相关的。

不知道你有没有被那些反智的数据气过，反正我是已经被气过好多次了。不论是API返回的数据，数据库里面的数据，还是一些老数据，这些数据在初期设计的时候就没有设计好数据格式或者因为程序员的失误将已经约定好的数据格式搞得混乱。对这样的数据做处理是非常恶心的事情，你得对所有的特殊数据做特殊处理，对所有可能出现的特殊数据做分类好做好规划；这是个非常繁琐的过程，并且你得自己一个人慢慢摸索，这会大大的减慢你的开发效率。

我遇到过三种情况的的数据异常：API返回与文档不一致的数据格式、数据库的异常数据和老数据兼容问题。每一次都让我想骂娘，都给我造成了困扰。

1.API返回与文档约定不一致：不论是第三方接口还是自己内部系统的接口，其数据格式、数据内容应该是已经定义好的，这使得我们不要知道其细节，根据约定就可以并行开发。但是据我亲身经历，不论是阿里、字节还是腾讯、快手，他们的一些API文档与他们实际返回是有出入的。
在我对接抖店消息的时候发现，订单消息中的子订单id有时候是1，而其文档中约定好是一定有值的，经过全面的测试后，我们发现其为1的情况是主子订单ID一致的情况，而其文档中没有写。这样的脑残API，导致我们不再信任其文档，然后对其每个API都得测试各种各样的情况后才可以放心进行开发。
API文档不可靠，这是一种非常糟糕的情况，这意味着开发者对其文档承诺的内容不负责，这也会导致使用方如果不了解细节的话，没有经过全面的测试的话，使用方的系统也是不稳定的，进而导致依赖使用方系统的系统不再稳定。解决这样的问题只有从根源处理，将系统功能与API文档描述一致，对各种特殊情况文档描述出来。对开放平台的文档尤其需要负责，因为它将影响很多人。

于是我们得到了俩个处理接口返回与文档不一致的情况的方法：
a.最根本的处理方法是通知API提供处理该问题，指出其描述不一致的地方并要求其更改（开放平台提工单）。如果提供方足够重视该情况就能得到及时的处理，同时也其他开发者也可以从中获益。这里所说的更改是接口实现与现有的文档描述保持一致，而不是修改文档。
b.使用方遇到这样的问题应该将其总结到文档或者注释里面，这样后来者也可以从中获益。新人就不用每次都得踩这样的坑。不要重复造轮子的一大益处就是不用每个人都从0开始。

2.数据库数据异常：这种情况都是系统内部的问题，可能是是设计初期没有设计好，也可能是程序员存了一个不和规范的数据。设计一个好的表结构是困难的，尤其是在现在俩周一个版本的，一个月一个系统的情况下，大家没有时间详细思考与设计表、数据库和系统的结构，规划表与表、库与库、系统与系统的调用或依赖关系。有一部分程序员是没有系统设计能力的，这导致他们设计出来的系统经常需要大改，于是项目就不得不延期项目组就不得不加班。这将导致一个恶性循环，越差的系统越需要投入人力（软件开发的主要成本就是人力成本）。就我的经验来说，大家都希望是快速做个可用系统占市场，然后一步步修bug完善系统。在当前环境下各公司也别无选择。
上面这些现实情况导致了数据库数据异常。比如我们有一个字段，modify_time，表示该条记录最后一次操作的时间，你可以想到这个字段是一个不为null的字段，并且他应当默认为当前时间，然而在你使用这个字段的时候却发现他居然有为null的情况；再比如有这么一个字段，status，表示该条记录的状态，在早期的系统中类型为int后来是枚举，如果你不了解这个系统的变迁又没人留下提示的话，我们很容易掉入这样的坑中。

而处理数据库数据异常情况的的方法也有俩个：
a.最根本的解决办法是做好数据库设计，表字段类型与默认值应该是怎么样的，表与表的依赖关系是怎么样的，需要在最开始就设计好。有几个小技巧：默认值优于null、有限状态的表示使用枚举优于使用int、为每个字段添加注释。
b.在变更表时应该产出相应的文档或者注释，编写需要使用到的工具。比如int改枚举你就应该为这个更改产生注释或者文档，并且写一个枚举和int相互转换的工具，这可以大大减少后辈的学习时间与开发成本。

3.老数据兼容：通常情况下数据兼容问题是大家没有一个统一的规范，想一出是一出。这样的问题经常出现在临时任务的数据产出与边缘功能的开发中。本来大家开发就很忙，接到一个临时任务肯定想着赶紧做完交差了事，自然不会对这样的东西花心思去设计数据结构；在设计边缘系统的时候容易陷入自己的圈子里，不顾别人的设计，然后大家做了同样的功能数据机构是完全不一样的。
在我的开发中就遇到过这样的情况，第一个是一个弹窗功能的开发，在先前的版本弹窗是运营有需求然后前端同学实现弹窗代码然后投放页面上的，这导致每一个人实现弹窗的格式都是不一致的，比如有的人标记关闭按钮是使用class为close，有的人则是使用id为closeArea，之后随着这个功能的实用性越来越强，决定开发一个统一的弹窗编辑器，不用每次前端投入开发人员去搞弹窗，并且老的弹窗不可能重新搞，你还得将老的格式转成棵编辑的格式；第二个是日志格式的问题，大家记录格式使用的关键字分割符是不一样的，有一天大家希望从这些日志大数据中分析出有价值的信息后清理一下日志。

处理数据兼容的情况有以下几个方法：
a.分析数据后给出一个统一的数据格式（定义一个标准），将所有的数据格式兼容成这个统一的格式并且以后不再允许自定义数据格式，大家统一按照规范来。就比如上文中的弹窗格式兼容最重要的就是定义一个统一的规范然后将老格式转换成新的格式。
b.在自定义格式的时候打上自己的标，比如多添加一个designby或者version字段，这样在做数据兼容的时候好做分类处理。
c.最根本的解决方法是标准先行，最好为标准产生相关和工具，然后实现定义的标准就ok了。

总之，不可靠数据的问题最终是约定（或者说是标准）的问题，假如API提供方和使用方严格按照文档实现那双方都不会有什么问题，如果一开始就一个好的数据格式标准，那数据问题自然也就不会有。

注：有什么意见或者建议请评论留言。转载前标明作者与来源。