开发踩坑记录

1.项目上一直报了个空指针，但是我就是看不出来到底哪报错了，感觉处处排空了，报错位置在倒数第二行的jdyInfos.stream()处，Service代码如下，后来发现是jdyInfos这个list中有空的Object对象，后来对jdyInfos的Object对象做了判空处理

 public List<String> getRequireBu() {
        List<RequirementInfo> requirementInfos = this.list(Wrappers.lambdaQuery(RequirementInfo.class).select(RequirementInfo::getRequireNo)
                .orderByDesc(RequirementInfo::getCreateTime));
        List<String> requireNos = requirementInfos.stream().map(RequirementInfo::getRequireNo).filter(ele->StringUtil.isNotBlank(ele)).distinct().collect(Collectors.toList());
        List<JdyInfo> jdyInfos = jdyInfoService.list(Wrappers.lambdaQuery(JdyInfo.class).select(JdyInfo::getSecondaryDept)
                .in(JdyInfo::getRequireNo, requireNos).orderByDesc(JdyInfo::getUpdateTime));
        List<String> list = jdyInfos.stream().map(JdyInfo::getSecondaryDept).filter(ele -> ele != null && StringUtil.isNotBlank(ele)).distinct().collect(Collectors.toList());//报错前
      //  List<String> list = jdyInfos.stream().filter(ele->ele != null).map(JdyInfo::getSecondaryDept).filter(ele -> ele != null && StringUtil.isNotBlank(ele)).distinct().collect(Collectors.toList());   //过滤空对象后，不报错了

        return list;
    }

 2、集群下使用@sheduled注解造成的坑，场景：

        生产上有一个定时任务，每天晚上12点执行，获得的部分数据要保存在第二天早上8点推送给用户，我的思路开始是用一个延迟任务，将晚上12点执行的得到的要推送的数据放到延迟队列里，但是最后没调研出来如何使用，后来就又添加了一个早上8点执行的定时任务，把要推送的数据放到redis缓存里，然后在早上8点从redis里拿任务，这个方法可行，但是我中间因为后端使用得是spring boot框架又用了@scheduled注解新建了一个config配置类开启定时任务，然后在本地的时候正常执行，但是部署到生产上之后，发现给用户推送的任务是双份，我怀疑是生产上的后端服务是部署得是双份，导致这个定时任务同时执行，而我对redis的操作是先从redis查询数据，然后推送消息，然后再给用户推送，最后删除redis中的数据【漏洞是如果在推送数据的时候失败，暂时没有重新推送机制】，所以导致了推送双份数据这个场景的发生。

3.开发时技术方案不确定没选好造成的坑

系统做得是一个效能分析平台系统，公司内的每个项目的经费都是走的简道云的审批，需求是要从简道云中拉取数据，但是简道云的一个接入机制是给简道云提供一个外网可以访问的api接口，当简道云的数据发生变化时自动给这个api接口推送发生变化的数据时，因为当时没打算把接口暴露在外网，而公司中另外一个项目已经接入了简道云，所以就打算接另外一个项目的数据，因为不是一个项目，数据库也不一样，当时采取得方式是直接连接他们的数据库，从他们库里直接取数据，当时恰好用得是mybatis-plus，所以直接使用了mybatis-plus的多数据源，后来就直接多数据源接入了，后来组长给得建议是直接连接他们的数据库接口上更方便，因为我不用再写向我们内部系统暴露对接的接口了，但是可能直接操作数据库对数据库不安全，后来我也没改，但是当从测试环境接入之后，要部署到生产时，发现内部系统的环境在生产上没有，然后只在测试环境部署了一份，当时领导和组长给得解决方案是要不让另外一个系统在生产上也部署一份，要不就让我外接简道云，后来他们又想到了另外单独做一个系统openapi外接简道云用于中间的桥梁，以后如果再需要外接其他东西时都用这个openapi，这个openapi使用的是阿里云的rabbitmq，后来我就又作为消费者接入了一下阿里云的rabbitmq，但是接入之后又发现接入简道云里的数据库里的数据和直接从简道云上下载下来的数据不一致，后来就又询问了一下原因，简道云上的数据比如在修改时推送给外接的api接口时可能会由于网络不好的原因导致没推送给外接的openapi，即openapi那边没接到改变的数据，那我这边也就消费不了数据，当时考虑了一下应该不是我这边的消费者出现了问题，因为我这边的消费者用的是手动的ack，即如果消息消费失败，消息不会丢失，而且在阿里云rabbitmq的控制台上看消息并没有累积，即消息按理都消费了，但是数据还是和简道云直接下载下来的不一致，那就意味着源头出了问题，所以应该就是openapi那消息没接收全，然后openapi那边说简道云推数据那没推全，会出现丢失消息的情况，所以就又开启了另外一个解决办法，后来又了解到另另外一个系统接过简道云的api接口，所以就又让另外一个同事帮忙重新接入了简道云的api接口，定时从简道云那边拉取全量或增量数据，最后思路是，先拉取全量数据做数据修复，然后再拉取当天一两天的增量数据，rabbitmq不变，定时任务作为保证任务准确性的一个辅助，里里外外一个功能大概弄了一个月。

4.上线的时候真的是最好要在晚上或者下午的时候没什么人用得时候上，因为我开发的是内部系统，目前内部员工没那么多人用，然后我就晚上不发版，等到快上班的前一小时左右才发版，中间真是有点惊险

5.jenkins显示部署成功  ！= 服务没问题，建议jenkins部署得时候看服务日志情况

6.有一个良好的分支管理习惯，不要把master分支的代码写的跟本地测试一样

7.不管是什么级别的职位，有事儿及时说是真的有必要的，没干完没有关系，你得让别人（领导）知道你干到什么程度了，他/她才能更好地做下一步安排

8.404问题场景：从网关转发到其他服务时，一直报404，我就特别纳闷，这咋会404，服务在jenkins部署的时候显示成功，这又回到了第5个问题，部署成功不代表服务正常启动，长时间的大眼瞪小眼，后来我同事说你看看nacos配置对不对，看看服务在nacos注册上了吗，我后来看了一下，果然没在nacos注册上，，原因是我当时的环境是测试环境，nacos配置中有阿里云的rabbitmq，rabbitmq就一个正式环境，如果我测试环境也在nacos配置阿里云的routing key的话，那么会消费正式环境的消息，所以我当时就把测试环境阿里云上的routing key在nacos上配置了一个不存在的key，导致consumer一直连接不上阿里云的rabbitmq，导致服务假死【自我认为】，因为改过routing key之后服务就注册上了

9.开发之前做好架构和数据库设计。因为刚开始数据库设计没做好，导致我在写一个接口的时候，对以前的接口重新修改了，几乎造成了我重新开发现在和以前的接口，数据库也没设计好

10.建议：如果是做数据统计分析类的系统，一定要做一个总计表和详情表，数据库的三范式一定要学好，用好redis缓存，不然会导致大部分查库，因为统计分析类的系统就是对底数据的再次汇总展示

11.上线之前，把代码合完了之后，一定要在本地大概跑一遍，包括前端、后端，否则如果是to c那就完蛋了

12.mysql少用like查询，尤其是在大数据量的情况下，like查询特别耗时间，数据量大的情况建议采用精准查询，另外在前端查询时注意形成好习惯，使用trim()把前后空格去除，给用户体验好点

13.建议后端新建一个filter，比如对前端数据是否要做一个统一处理，另外建议多用JSR303校验（虽然我用的少）

14.建议在使用rabbitmq时，作为生产者一定要加一个唯一的msgId，否则比如因为是集群环境，要给消息加分布式锁时，key不太好加，另外就是使用手动ack