09:02 到公司 09:03-09:07 整理桌面卫生 09:08-09:20 查看处理git上面的事情 09:21-10:15 处理git服务器挂掉,本地无法获取配置文件内容 10:16-11:11 思考增加合伙人中代理人提交给用户确认的问题 11:12-12:30 整理项目内容上传到git服务器 12:31-13:30 休息 13:31-16:07 处理各个环境的jenkins配置 16:08-18:57 处理完很久之久的修改附件接口
1.思考增加合伙人中代理人提交给用户确认的问题 2.整理项目内容上传到git服务器 3.处理各个环境的jenkins配置 4.查询合伙人提交给用户确认和用户确认出现的问题,都是参数的问题,程序没有问题 5.处理完很久之久的修改附件接口
技术: 1.对于配置中心的配置,不能完全保证取自于git,如果git挂掉,一定能从config服务器本地获取配置信息的内容,从而实现高可用,本次git服务挂掉,微服务彻底挂掉,体现处高可用的脆弱性,如果上线,git服务挂掉,那么微服务不能使用,这个真的玩大发了啊.所谓微服务必须做集群,必须实现高可用,不然微服务的弊大于利.这次是给我非常大的感触. 2.每次因为业务的不同对代码的影响,我都需要未来的拓展和维护性啊,加在这里是不是合适,和应该,同时尽可能缩短这段思考的时间,对业务快速相应啊.
思考:1.合伙人的业务不熟悉,导致后期我这块的东西不断修改修改,不断冲击我这块的业务,因此订单的所有业务的介绍我都需要进行参与的啊,因为合伙人这些破烂的事情,耽误我那么多时间去了解业务,如果我当初参与熟悉下业务也不会有这些问题了.结论就是订单业务的需求,我都参与,其他的不必管,也不想参与,事情够多的了.2.合伙人的提交给用户确认,合伙人业务和深度优化的不同,我考虑要不要合并在一起处理,如果在一起处理,后期的增减项问题是不是存在很多问题,我是否需要考虑这些问题呢?因为之后的增减项问题同样超过多个尼斯分类个数问题,所以这块目前合并在一起处理完成. 3.其实用户模块,合并的理由都陈述了,和订单模块的业务耦合性太高了,所以我才合并到一起的,节省内存只是打草搂兔子而已,顺带的.同时以后没必要解释这些东西,既然是我负责的,那么我处理,责任我负责.其实还是自己的技术级别不够高,说话和做事可能被质疑.
