1. 前端任务拖动相关bug 17-10-27

初步判断是sortday.但查看sortday返回的数据没问题.不包含新数据. 这里的sortday还并不是全部逻辑,只是现在的情况不会有sortday导致, 后端解决不可行,服务器压力大,难以判断sortday的修改. 1、前端修改sortday排序逻辑 2、前端每次修改sortday内容.

0.1. 时间日志

  • 07:25 醒
  • 08:20 起床
  • 08:30 洗漱1
  • 09:07 早饭
  • 09:07 卡通
  • 09:45 美术设计稿反馈&查看前端发来的bug
  • 10:42 厕所
  • 10:54 烧水泡茶吃枣回答群问题
  • 11:27 前端任务拖动相关bug
  • 12:32 午饭
  • 14:07 吃零食的习惯,有人休息时抽烟,额外的零食开始导致吃东西成为习惯.
  • 17:26 项目完善 17:26手机项目成员管理-part3
  • 18:14 晚饭
  • 18:14 卡通
  • 20:05 前端沟通任务详情和Bug
  • 20:38 卡通
  • 20:58 洗漱2
  • 21:58 妈电话聊天45分钟
  • 22:26 卡通
  • 项目完善

0.2. 总结

0.3. 观点及其他

0.4. 任务详情

0.4.1. [x]妈电话聊天45分钟

创建 完成 聊学些成长,时间太长逃避不想听了。

0.4.2. [x]烧水泡茶吃枣回答群问题

创建 耗时 开始 完成 早饭中买的枣. 在回答问题中对方中是听不明白,没法在解释了. 说对方经验少,对方也说我装逼.

0.4.3. [x]吃零食的习惯,有人休息时抽烟,额外的零食开始导致吃东西成为习惯.

创建 完成 有点像富足后多余的诱惑引发的一系列蝴蝶效应.

0.4.4. [x]前端沟通任务详情和Bug

创建 耗时 开始 完成

0.4.5. [x]前端任务拖动相关bug

创建 耗时 开始 完成 暂停 继续 初步判断是sortday.但查看sortday返回的数据没问题.不包含新数据. 这里的sortday还并不是全部逻辑,只是现在的情况不会有sortday导致, 后端解决不可行,服务器压力大,难以判断sortday的修改. 1、前端修改sortday排序逻辑 2、前端每次修改sortday内容. 后端没有返回数据,前端的错误数据从哪里来的?axios 协议缓存吗?经过测试发现不是,但这个可能出现问题?只要数据没有出现旧数据覆盖就不会出现问题. 那就需要检查旧数据覆盖 猜测是前端列表是使用过了clone数据,修改列表数据导致不是修改真实。查看代发发现已经没了clone. 7天时间清单 看起来也不是store.js的问题. 那问题可能在哪儿呢?首点击“月”后就出现这问题, 在“月”里面有clone数据. this.weekList =weekList; Object.assign([], this.weekList, weekList) 7天时间清单

0.4.6. [x]美术设计稿反馈&查看前端发来的bug

创建 完成

0.4.7. [ ]项目完善

创建 预计

[ ]手机项目成员管理-part3

创建 预计 完成 暂停 继续 暂停 继续 暂停 继续 暂停 -页面独立 30m s7天时间清单 e17-10-26 7天时间清单 添加项目的布局独立好了,调整了显示模式按钮组样式. 7天时间清单 调整header标题, 7天时间清单 添加项目和编辑项目放在一起. 7天时间清单 -两个项目整合 1h 7天时间清单 修改字段,调整接口,调整接口逻辑; 调整成员为空时的布局,需要修改width: 54px; 7天时间清单 添加项目成功,删除项目后修改选中项目报错,因为在不同文件中. 7天时间清单 监听项目列表,如果项目列表长度变化就修改当前选中项目. 7天时间清单 z39&z43项目整合, 获取成员列表修改, z39的两个表删除吗? 登录loginmob接口this.action("apix/d7game", "usersession")报错, d7game.js中完善uid后正常. 7天时间清单 z43friend 表中主要是使用pid? 是的,之前这里主要是用于查询电话. 需要调整pid为uid,可以提交效率. 现在已经有了uid字段,但意思不一样. 主要是作为通讯录使用. 但z43phone项目中只能使用pid? pid是对应一个电话id,不是一个用户. 只是有“张三”的电话号码,张三没有注册并没有uid. x 为了使用饿了么外卖红包4元,今天额外订餐10分钟,花费了60元不必要的水果和零食. 7天时间清单 z43和z39两个项目数据有点不一样, 昨天是构思邀请通讯录好友时对手机号进行预注册,预注册后会对注册绑定账号照成一点影响, 登录页面就不能直接使用手机号注册登录,添加一个字段(或通过login次数)就可以区分. 7天时间清单 如果用户表中的数据过多时会怎样?加入100w个用户数据,查询会需要多超时间. 判断是消耗数据库内容,需要提升数据库服务器配置.这个观点需要找更专业的人确定. 7天时间清单 pid可以改为fuid-frienduid, 项目成员使用 gid和uid. 通讯录使用fuid和uid俩字段. 当初任务这两个表字段名相同,就放到了一张表里面. 以后还能分开成俩表吗? 如果没有fuid就能区别并分开. 不影响原来z43系统功能,先过渡性新增字段. 后期完成后端逻辑后,在删除弃用字段pid. 7天时间清单 -调整接口(usertask,z39project,z39projects) 相关需要调整前端的字段吗?group字段名已改为title. 还需要修改相关弃用的z39member表, pid->gid , 其他表还使用了pid,所有都修改吗?最好全部修改.后端65处变量引用,并且还有前端. 在后端修改project为group, 只修改后端gid变量. 前端哪些地方使用了pid?85处引用. 感觉有点纠结. 7天时间清单 修改masters字段为uid,测试获取usertask,获取项目信息正常。添加项目报错 SQL: SELECT * FROM d7_z39tagitem WHERE ( uid IN (-1,0) ), proKeys [] [] { TypeError: Cannot read property 'id' of undefined 这里修改逻辑后,获取所有标签失败. await this.action("api/z39tagitems", "get"); 看不到报错来源有点麻烦,逐行检查也没看出. 7天时间清单 逐行添加打印代码发现问题出在 await this.model("api/z43group").addRecord(item); 切换为z39project后,这行插入数据成功,其他地方出现同样问题.this.model("api/z43friend").addRecord({ uid, gid }); 都是被修改的2处地方 7天时间清单 查看model文件发现是旧代码参数更对,需要"db". 删除后正常. 7天时间清单 添加项目、删除、修改正常. 7天时间清单 -项目成员获取展示逻辑 20m -成员增加或删除 40m -模板管理

Copyright & copy www.7dtime.com 2014-2017 all right reserved,powered by Gitbook该文件修订时间: 2017-12-24 15:03:46

results matching ""

    No results matching ""