08:15 到公司 09:16-08:19 整理桌面卫生 08:20-08:22 整理内容 08:23-08:44 处理金额计算逻辑和测试,修改文档 08:45-08:49 休息 08:50-09:14 处理单笔和批量金额支付前校验代码重构 09:15-09:21 休息 09:22-09:35 处理单笔和批量金额支付前校验 09:36-09:47 深度优化项目早会 09:48-10:22 处理深度优化测试环境合并和构建 10:23-10:27 休息 10:28-11:52 将代码合并到pre测试支付回调 11:53-13:46 午休 13:47-15:29 处理完成支付回调的问题 15:30-**:**
1.处理金额计算逻辑和测试,修改文档 2.处理单笔和批量金额支付前校验代码重构,文档修改 3.将代码合并到pre测试支付回调 4.处理完成支付回调的问题
技术: 1.订单编号首字母作用到期要不要用到业务中,首字母到底应该有什么用呢?要不要和业务挂钩呢?如果挂钩到什么程度呢?没有答案啊. 2.真是上面随便一说,累死下面一群人啊,今天感触非常深刻啊.如果随意改动基础业务逻辑,很多东西真没法做了啊.
思考: 1.昨天突然想到的问题,那就是金额计算的展示问题,因为存在发票费包含在服务费中的问题,那么需要有选择的展示,问了沈哥,说自己又查询了一遍数据库,其实这个问题沟通好了,我处理下,一次性返回就好了啊.体现的问题有2,第一我考虑问题不周啊,同时有个问题,那就是任何人都无法面面俱到的,需要大家沟通协助的;第二就是沟通协作的事情,也许沈哥看我太忙了,或者我忙忘记了,所以自己处理的;第三,这个是和江东说的比较多的,就是如果php实现困难,那么我们Java来处理简单的话,那么Java来处理,如果Java处理困难,那么php处理简单,那么就php处理,从这一点和江东的沟通很到位的,反正都是为了工作,不一定非要强加给谁去处理的. 2.我有预感,直接数据库修改订单金额价格,一定会存在非常多的隐患和后续操作的问题,这个问题并且一定非常难搞的啊,因为这些数据是金额的源头,没有金额的数据流发生,从源头的数据就不复合规则,后续金额计算除非摆脱源头,使用基本数据进行计算,否则一定会出现非常多的问题. 3.邮件问题,发送邮件的时候自己考虑是否需要别人回复,如果应该发送,不回复,无所谓;如果需要是否应该发送,如果应该发送,那就发送,不用考虑别人是否回复;如果值得值得发送,那么就需要进一步思考,是否值得.如果不值得浪费时间,那么就不处理.
业务总结: 1.昨日和穆哥,增勋说,金额计算,支付前金额校验,支付回调已经说明,都以支付订单以数据库字段使用,目前不使用原始数据进行计算,这样存在的问题已经思考过,目前不做处理,因为存在管理后台修改数据的情况存在.同时任何支付方式都不需要计算平台支付费.都以数据库字段中支付订单表中字段为主.