09:03 到公司 09:04-09:07 整理桌面卫生 09:08-09:20 整理上周周报内容 09:21-09:34 组织Java组早会 09:35-09:43 休息 09:44-10:06 思考接口安全设置内容 10:07-11:55 测试完成修改商标订单同步支付订单更新时间 11:56-13:09 午休 13:10-13:39 测试保存附件更新支付订单更新时间 13:40-13:45 休息 13:46-14:42 测试保存附件更新支付订单更新时间 14:43-14:47 休息 14:48-15:16 测试保存附件更新支付订单更新时间 15:17-15:22 休息 15:23-15:52 测试保存附件更新支付订单更新时间 15:53-17:00 测试保存附件更新支付订单更新时间 17:01-18:30 给Java组讲解微服务发现原理和网关实现原理
1.测试完成修改商标订单同步支付订单更新时间 2.给Java组讲解微服务发现原理和网关实现原理
技术管理: 1.今天发现tk.mybatis的条件设置属于能进不能退的情况,可以不断向里面增加条件,但是如果你想根据对象把当前的条件内容都重新获取修改或者做其他处理的时候却比较难的,比如今天在后置通知中,唯一能拿到的内容就是example,从里面抠出来查询条件实在比较困难,设置框架框架或者工具类的时候都需要思考着,技术不可以走单行线,业务同样不能走单行线的. 2.记得当初在a站就有这种情况,开发功能看似做完了,没有测试完成,没有完善好功能,其实就是半九十的完成,那么重新接手的人去开发就需要去了解业务去处理,事情非常的多,非常不好的行为,一定是自己去开发完,然后给别人去维护,而不是开发个半截子,然后给其他人去开发维护,这样非常浪费彼此的时间.
思考总结: 1.修改商标订单同步支付订单更新时间开发了很久,但是使用笨拙的方式和使用有技巧的方式处理是截然不同的感受和成就,可以在每个方法后面增加个方法,可以使用spring的通知,只是如何处理更加地优雅而已.最直接最笨拙横冲直撞的方式,没有几个人是不会的,那也是做开发吗? 4.测试不成功,哪怕你认为非常简单的功能,只要没有彻底测试完成,都不是完成功能的.比如今天原以为测试测试就没有问题呢,但是发现这些东西自己确实以为处理完,实际上根本不是那么一回事,以后所有的东西,必须以测试完成作为结束,还差点测试,谁知道测试验证下来,倒是有多少时间呢.
