ferrero项目的思考
一、做一个项目的过程当中必然会遇到很多问题
客户变更、自己对需求的理解不到位。代码不够严谨，bug众多
我们应该要养成一个好习惯，开发的过程的当中做好记录，遇到的问题，记录下来。
要做的功能多思考，最大程度上避免测试让你修改bug
## 平时说的一些业务上的需求，我没有很认真的记下来，应该写到txt里，我只是凭记忆，
而记忆不是个很靠谱的东西。
一些问题，难搞的。忙的时候暂时没有解决，也没有记录，暂时没有被发现，我就忽略了。
等到最后这些问题你还是要解决的，我应该记录下来，如果暂时没有空解决，等后面有空了，去解决。
换而言之，我并没有很认真的去对待这些接口，每一个查询，每一个功能，是否做到满足了需要？
满足业务需求，性能也ok
1.1 从第三方拿数据，我一直以为是他们提供SFTP, 我们到时候去拿，就等啊等，最后要联调了我问
他们的sftp呢，说是我们自己的sftp，然后sftp配置在其他人哪里。。
所以这个要早点问，不然自己早就可以调试了。
自己在调试SFTP时也遇到了问题，之前用过好几次sftp 都ok，但是对于这个的理解太浅显。
这次算是认识更深刻了，以后再做sftp应该更加得心应手了
bug1
第三方数据入库，根据主键业务编码，查询，返回List 存在直接delete
然后统一入库
感悟
一开始考虑功能，其次要考虑性能。考虑数据量大不大。
如果优化，索引，查询字段等待方式
bug2
申请序列码功能
切面报错
RequestContextHolder.getRequestAttributes() 空指针，其他方法ok
一查发现，我的方法是在@Async注解下，异步无法获取request，解决办法，不让切面切到。
切面切的是service的create、update等方法，修改方法名不匹配即可
BUG 序列码申请功能速度很慢
序列码生成，需要查询最大的流水号，然后生成的数字递增
发现mongodb第一次查询的时候速度非常慢
Query query = new Query(); query.with(new Sort(Sort.Direction.DESC, "snNo")); query.skip(0);// 从那条记录开始 query.limit(1);// 取多少条记录 List<SerialNumber> list = mongoTemplate.find(query, SerialNumber.class); if (ListUtil.isEmpty(list)) { return 0; } return list.get(0).getSnNo();
MongoCursor<Document> cursor = mongoTemplate.getCollection("serialNumber").find().sort(Filters.and(Arrays.asList(
Filters.eq("snNo", -1)))).skip(0).limit(1).iterator();
//List<SerialNumber> list= new ArrayList<>();
while (cursor.hasNext()) {
JSONObject jsonObject = JSONObject.parseObject(cursor.next().toJson().toString());
JSONObject snNoLong = JSONObject.parseObject(jsonObject.getString("snNo"));
Long snNo = snNoLong.getLong("$numberLong");
//String snNo = jsonObject.getString("snNo");
log.info("snNo=" + snNo);
return snNo;
}
return 0;
随着数据里逐渐增大，这个速度变得非常慢需要10秒。
（对于一些功能 一些方法添加时间监控非常的有必要）
后来考虑其实流水号和业务无关，既然sql查询无法优化，考虑加一个表存贮即可
SnMax snMaxEntity = snMaxRepository.findByIdAndIsDeleted(CommonConstants.SnMaxId,0); long maxSn = 0; if(null == snMaxEntity){ maxSn =100888880; }else{ maxSn = snMaxEntity.getSnNo(); } public static long getMaxSn(long maxSnNo, int count){ return maxSnNo+count; } public static List<String> genarateSN(String marketCode,SerialNumberRule rule, String gtin,long maxSnNo, int count) {} if(snMaxEntity != null){ snMaxEntity.setSnNo(SerialNumberBuilder.getMaxSn(maxSn,newGenCount)); snMaxRepository.save(snMaxEntity); }else{ SnMax entity =new SnMax(); entity.setId(CommonConstants.SnMaxId); entity.setSnNo(SerialNumberBuilder.getMaxSn(maxSn,newGenCount)); entity.setIsDeleted(0); snMaxRepository.save(entity); }
BUG 序列码申请100只拿到70
这个问题的发生是由于代码执行顺序，当有多个用户共同操作的时候引发的
有一个码池的概念，码池里存了50码。当用户A申请了100个，发现码池有50个，
然后工具生成50个，从码池拿50，顺序是先自己生成，然后从码池拿，
结果当去码池拿的时候，里面已经没有50个，被其他用户拿走了30，所以最后生成了70
真正的思路应该是：先从码池拿，根据实际拿的数量，然后再生成差的。最后数量就不会错
BUG 字符串转 ZonedDateTime 问题，因为时区的问题
注意从第三方拿到的是字符串"2019/6/29 0:00:00" 存出入库后没有细看存储的Date类型的值
public static ZonedDateTime parse(String strDate, String pattern) { SimpleDateFormat df = new SimpleDateFormat(pattern); try { final ZoneId systemDefault = ZoneId.of("Asia/Shanghai"); return ZonedDateTime.ofInstant(df.parse(strDate).toInstant(), systemDefault); } catch (ParseException e) { e.printStackTrace(); return null; } }
实体带状态的，展示的时候重新设置值，用枚举
注意：
改完bug一定要本地测试通过，再发到测试环境。而不要凭感觉，觉得这里改一下就Ok l
mongodb 列表查询按照时间倒叙发现很慢，我之前加过索引。
在mongodb数据库里查询，发现也要十几秒，说明代码没有问题，
使用explain 查看执行情况
db.getCollection('serialNumber').find({}).sort({"createdDate":-1}).skip(10).limit(10).explain("executionStats")
发现没有命中索引，命中索引 是
删除之后，重新创建索引为 -1 ok，查询很快了
bug 发现问题 如果没有parentSn 可能会get到空字符串，然后查询出太多的数据，GC了
pallet carton tray 三级，有pasn关系。
传入carton的sn值，根据carton的pasn，
先更新pasn的数据，然后根据pasn，查询出所有的carton
最后更新tary
应该加一个判断，如果carton的pasn是空的，那么就会有问题
