慎用非结构化数据

在nosql、json、map满天飞的年代，我还是喜欢用实体类包装的结构化数据，因为实体类结构化数据编码方式总会给我一种踏实感。

文章中讲的结构化数据，指关系型数据库的每一行数据、编码中的实体类。

在日常工作中，开发业务代码者应该还是居多，也有一些少数是开发功能性的中间件。

开发业务代码，应该在业务功能实现的同时，还需要特别注意代码的可读性和功能的扩展性。

这其中有一条铁律，即慎用非结构化数据，包括但不限于map、json。

刚参加工作那会儿，在电商公司负责营销板块银行卡支付打折活动。

业务场景是这样子的，使用工行卡支付，打9.8折，使用中行卡支付，打9.9折，在预见的将来又会有建行卡9.5折这类型的营销活动。

如果是你来负责，你在设计思考的时候，会思考哪些方面呢？

当时的实现方式是直接把营销活动信息（活动类型、折扣率、支付推荐语…）序列化存入数据库当中，当时还沾沾自喜的想着，我这个扩展变更很灵活，需要增加新功能的时候，不需要进行数据库的字段变更，但是牺牲了数据库层面的可读性，后来经常因为反序列化key不存在出过几次生产事故，大致是以为反序列化后存在某个key，实际又没有该key，迫不得已只能在代码上对反序列化结果做格式判断，从而导致非业务代码增加，又降低了代码层面的可读性。实现方式还有一个弊端，非常不利于功能扩展，营销活动信息会逐步增加，新版本扩展了新的序列化字段，在新版本上线的时候，对原来的数据，需要进行初始化，增加了运维成本，如果没有考虑初始化，到又会出现上面反序列化key不存在的问题。

上面是一个很好的反面例子，在设计思考的阶段，只考虑了业务功能的实现，没有充分考虑可读性与扩展性。

根据我的理解，把可读性从优到良分为4个层次：

**1.代码可读，数据可读 **

**2.代码可读，数据不可读 **

**3.数据可读，代码不可读 **

4.代码不可读，数据不可读

最近团队重新做质量追溯的功能板块，复盘去年设计一个追溯数据存储方案，又犯了类似的错误。

使用了非结构化数据Map（可以理解为MySQL的json格式）结构进行了数据存储。

犯了考虑问题不全面的错误，只考虑了功能的实现，没有考虑数据后期的可读性与维护性。最后导致采集的数据根本没法用。

现在复盘一下，我们采集数据应该自顶向下的来进行思考，思考采集数据的目的是什么？

是为了把数据采集上来存进数据库？还是为了真正的把数据分文别类的存储起来，然后把数据利用起来？当然是后者，我们当时连采集数据的结构都没有定义清楚，尽想着功能的灵活性了，后来纯粹的把事情做成了前者。

在v2.0的版本上，强调要使用结构化进行存储，没有把结构思考清楚，不进行数据存储。

重点要把输入和输出的数据结构定义好，将来优化逻辑，重写可控，测试也可控，反之则根本不敢动手，因为非结构化的数据扩散至项目的各处，不能评估其影响范围。

不要写太“灵活”的代码，灵活就是给垃圾代码、垃圾数据提供给有利的生长环境，让代码看上去“呆”一点，一段代码只处理一个业务，就算几个业务之间有逻辑重复的地方，复制粘贴重复的代码也是可取的，一切从业务出发，业务是独立的，代码就应该是独立的，应该由业务定义代码，而不是代码来定义业务，因为业务现阶段看似一样，将来差别可能会很大。

一个好的架构中，可读性和维护性是高于业务的实现，因为没有保护好这两点，后期将会需要投入更大的人力来进行维护功能与重构工作，而保证可读性和维护性，慎用非结构化数据是铁律。