最近两天开发问题的总结

复盘一下周二的提测:

问题一: 在代码中对于一些不确定的查询数据没有进行数据的校验
导致的结果: 查询的过程中, 查询到了, 上万条数据, 后序的处理流程中又根据这些大量的无效数据进行查询操作, 使得系统很慢, 响应时长 8s
解决方案: 在代码中加上对应的判断判断条件, 事无巨细, 建议不确定的都加上判断 , 保证系统的健壮性 , 同时在可能出现的问题点抛出可以识别的异常代码和信息 , 方便快速的定位问题出现的原因

问题二: 对于抛出的日志没有按照规定进行打印
导致的结果: 抛出了大量的日志信息, 而且无用的为多, 查询具体的结果不方便
解决方案: 输出问题点(日志), 具体而且细致, 标示性强的符号, 方便一眼就能在大量的日志信息中定位到需要的信息
例如:

log.info("============我是日志信息================调用方法的============入参"+data);

问题三: 对于日志的利用没有达到效果, 没有能快速的查询到需要的信息和根据查询到的信息在代码中进行问题的定位
导致的结果: 首先发现问题点慢, 很慢; 其次, 没有快速的在代码中找到相应的结果
解决方案: 1. 管道符和grep 的配合直接输出需要信息的日志

tail -200f user-info.log | grep "user_id_654321"

2.根据抛出的错误异常, 在异常中找到对应自己开发的代码的 类名和相应的行数, 快速的定位问题.

问题四: 不善于定位相应模块的分模块,分布式日志
导致结果: 在api模块居然想查看 user 模块的打印日志…真尴尬
解决方案: 先查看对应问题出现的模块, 再去相应的模块查看具体的日志信息, 以及对应sql脚本和相应的入参数据, 进行数据的定位操作

问题五: 考虑的不够全面,细致
导致的问题: 边界情况的出现, 溢出等
解决方案: 多想想, 多思考