快递e栈项目总结

码云地址：https://gitee.com/shujuanlanyan/expressEStation.git

快速e站项目计划表：

必做模块21个，选做模块至少11个，

时间争取6天，前4天争取完成21个必做模块，后2天争取完成11个选做模块，优先完成会的优先必做模块

平均每天至少5—6个模块，先完成后台管理再完成微信端，前期要先看视频所以前少后多，每天至少8小时

24日：必做模块 后台管理 1-4 数据库设计 后台管理视频

25日：必做模块 后台管理 5-12

26日：必做模块 后台管理 13-14 微信端 1-2 微信端视频

27日：必做模块 微信端 3-7

28日：选做模块 后台管理 1-5

29日：选做模块 微信端 1-6

30日：扩展

什么是复盘？

  完全回归到实物原生状态，解剖所有与其相关联的环节，一件一件去回忆、分析、解释、阐述，最终需要得到一个更好的可能性。

  复盘不是一次性的“行为艺术”，它是一种持续性、连贯性、递进式的旋转向上的动作。这个行为可以一人参与，可以多人参与，

  但原则上是所有与之相关联的人和事都要参与。并且复盘的关键在于及时、迅速、有效、反复。

为什么要复盘？

  1.知道“坑儿”在哪儿，避免重复犯错

  2.知道团队的强弱项，分工更趋合理

  3.知道“敌我”双方的实力，磨练心理战术

  4.知道“更好的可能性”在哪儿，胜在细节

  

怎么复盘？

  1.回顾目标：当初的目的或期望的结果是什么；

  2.评估结果：对照原来设定的目标找出这个过程中的亮点和不足；

  3.分析原因：事情做成功的关键原因和失败的根本原因，包括主观和客观两方面；

  4.总结经验：包括体会、体验、反思、规律，还包括行动计划，需要实施哪些新举措，需要继续哪些措施。

遇到的问题：

1.后台管理快递修改时没有调用修改状态时改变取件码的方法updateStatus()，按理应该无论是否修改状态，取件码都不变，为什么只有当状态变为已取件时取件码置空？

2.前台添加用户号码和身份证号不可重复问题及不可为空验证

不可重复问题明明设置了异常捕捉，但是控制台仍会报异常，没有按我的想法输出

3.快递表里的姓名和电话应该是收件人的名字和电话而不是用户表的账户（用户手机号），

快递表里应该有一个用户id来关联用户账号，bean里面一存多的集合，多存一的对象

4.微信端添加注册功能，登录时如果表里没有数据，就注册用户，无法注册快递员

5.页头菜单不能正确跳转

解决：都是前端的错

6.个人中心修改信息接收验证码时一个验证码可多次使用的问题

解决：每次修改完成删除存的键值对，有没有必要？原理是验证session中是否保存了一个userPhone-code的键值对，如果不删，除非清除了session，否则键值对一直在，下次再修改直接填原来的code仍然可以通过，所以要删

7.快递员登录失败，原因是登录时存的是user类，不是courier类

解决：所有快递员也是用户

心路历程：本来想把所有快递员数据加入用户表，即快递员即是快递员也是用户，登录时session中存储user类，但是登录时无法区分权限，失败。

第二种直接在登录时区分权限，保存不同的类型到session，然后每次取出都要进行判断，需要寻找加入大量if，放弃

第三种，舍弃快递员表，全部加入user表，并在user表增加权限字段，这样快递员类就不能使用，即一个user类需要对应两个dao，sql需要按需增加权限判断，剪切user类，将快递员类改名为User，通过idea改名时的关联操作，一键将所有用快递员类的地方修改为User类，然后删除快递员类，粘贴回User类，这样登录时都是User，按照权限字段判断权限，主要修改的bug在sql的使用，增加了多种dao方法应对不同场景使用

8.增加了快递状态由已签收变更为未签收时也要重新发验证码功能，本来是想应对快递员误操作提前签收的情况，可是老师说，这种快递员提前签收的情况不应该存在，我想是因为快递员只用输入取件码或者扫码才能确认签收，而这些都是用户提供的，故不存在提前签收

9.插入重复单号提示不报错

10.狗币的表单验证，有的对有的错，搞死人！！！在写验证的方法时，不光不符合正则表达式是要返回false，正确时更要返回ture，否则在调用这些方法判断时容易出错

11.不光插入会有重复的异常，更改也会

12.月榜报错，因为1号到了只有一个人在排名，list取不到后面的值！！！

13.关于模型类的设计要不要加入一对多，多对一

验收老师点评：展示自己所学，为未来的项目加分

1.列表提供删编辑操作，不要被模板限制

2.数据库中的数据不能直接删除，可以改变状态，且要二次确认

3.新增的功能是否合理

4.面试不能主动暴露缺点

5.敏感数据密文展示

7.多条件模糊查询，例如按照姓名、公司、单号等

8.列表要按时间倒序排序

9.添加后自动跳到列表

部分收集的资料

https://blog.csdn.net/HerryDong/article/details/105082284   表单内增加按钮

在浏览器控制台输入：

输入："express_123".indexOf("express_")

输出：0

输入："express_123".substring(8)

输出："123"

 

https://blog.csdn.net/zgrkaka/article/details/83382278

location.href跳转页面时传递参数并且在新页面接收参数：

https://blog.csdn.net/qq_29072049/article/details/80221694

森哥建议：

1.开发之前先考虑清楚流程，表的设计先考虑清楚，统一设计，形成闭环

2.持有怀疑的态度，自己做思考辨别

3.关于一对多、多对一实体类的设计，除了单独的实体类外，设计一个只包含“一”的对象和“多”的集合两个属性的类

4.登录时，如果主页需要直接展示快递数据那么登录时直接联表查询，否则只先单独查用户数据，别的数据后期查

5.关于删除数据，数据表里改变数据的状态字段，用户号码不加唯一索引，不要靠数据库异常来判断重复，应该靠代码逻辑解决，比如说先查询一遍，靠SQL异常捕捉更浪费性能

6.单例，工厂，策略三种模式需要背，应对面试

7.首先做好Java本身技术，适当做扩展，不要太过，等基础扎实完善之后再深入