2019年的bug汇总与开发注意事项6. 191213--验签中的null对象--3小时系统A调用系统B的接口，系统B

问题实录

系统A调用系统B的接口，系统B的接口有验签功能。验签过程是系统B获取到参数，对参数解密后计算签名，对比此处计算好的签名和入参sign值，值一样就ok。

调试时发现，对于某个用户的数据，系统B总是返回“验签失败”。

确定A，B系统的获取签名的过程是一样的，且秘钥没错后。查看该用户的报错数据，发现该用户的某个入参一直是null。

A调用B系统会同时传根据入参获取的签名值，以及加密的入参值。假设存在值为null的入参sampleParam，

获取签名时：

获取该参数的值并toString，它的值就会变成字符串“null”

获取加密入参时：

获取该参数的值并加密，加密后的值仍为null对象

也就是说，B系统从签名中获取到sampleParam的值为字符串“null”，但是从加密参数中获取到的sampleParam的值为null对象。因此验签总是失败。

可以优化下验签过程，A系统在调用B系统传参时，剔除值为null对象的入参，并且用不存在值为null对象的入参们获取签名。系统B在接受入参时，剔除掉值为null对象的入参。

本地启动系统B的服务比较麻烦，所以我在系统A单测获得签名，复制签名到系统B中单测的方法自测。

调试的时候发现系统B中获取到的签名与系统A中获取到的签名不一致。

因为两个系统采用不同的编码格式，我一直怀疑是编码格式的问题，但是多次转换后仍然没有解决问题。

实际原因是将系统A中获取的出参粘贴到系统B的idea编辑器的过程中，出参值中的自动"\r\n"合并为"\n"，导致二者获取签名的入参实际不一样另外，在idea的编辑器中copy的是\r, paste出来的是\n。 idea毕竟不是纯文本编辑器，还是需要对这种使用警醒一点。

发版前拉了下这个版本提交过的代码，发现这个这个版本对三个系统我总共提交了29次代码，其中只有9次是代码提交，20次是修复bug的提交（占到了68.97%）。

这样的频繁修改bug无疑是影响开发和测试效率的，确实是需要改进的地方。如果有问题影响到

原因的话应该是开发前没有全局的观念，导致初版代码没有考虑到情况很多。

需要关注安全问题，基础的越权问题，敏感数据特殊处理问题不应该犯

某功能要求将从源头获取到的数据脱敏后展示，源头数据为有固定模板的文本。

实现方法获取到数据按照模板解析出关键数据并脱敏，然后将脱敏后关键数据替换到模板中再展示。为避免每次获取数据都重复“解析关键数据--脱敏---拼接关键数据”的过程，首次解析到关键数据并脱敏后会将已经脱敏后的关键数据存储到数据库中，这样下次来就只需要做“拼接关键数据”。

展示数据不全

查询数据库中脱敏数据的时候用了distinct，因为脱敏数据信息是不全的，distinct会导致将本来不重复的数据排除掉。

例：假设我要对姓名脱敏，客户A的姓名是“李一二”，客户B的姓名是“李三思”。脱敏后两人的名字都是“李**”，distinct以后本来不同的两个客户的名字，就变成了同一个。

感觉在数据库里存脱敏数据的自己傻傻的。。。

  regexp_replace(regexp_replace(T.MOBILE_NO, '\\+86|-|_| ',''),'^860|^086|^86|^0','')

不同系统不同文件的编码格式，使用中文的时候记得转换成unicode
尽量不要捕获Exception这样的通用异常，而是应该捕获特定异常。Exception会隐藏意图（具体是在处理哪个部分代码的哪个功能）
写sqlmap的parameterClass时尽量用map，不要详细到map的具体的实现(入： LinkedTreeMap、HashMap等)。
数据写入操作时需要注意的点（同步，插入，更新等）（1）源头数据的表结构：字段定义（含义，类型，长度，精度）
（2）对于同步，源头数据的现存索引与分区情况，关系到同步效率
（3）写入表的现存索引与分区情况，关系到写入效率
（4）写入表的表结构（含义，类型，长度，精度），含义是否对的上，字段长度是否可以兼容
（5）了解源头数据的值，例如关键字段是否可能为空等
190916，开发需求前一定要够清楚是谁在用这个功能，功能是怎么被使用的，这两点是开发的必要前置工作。