项目总结

所做工作
人事模块接口编写;
工作台模块接口编写;
其他模块(主要是业务)新增功能编写;
新增及修改功能的测试;
遇到的困难
  1. 尝试使用Redis,但是不熟练,没有按照层级命名,逻辑也写挂了,一直都在读缓存;

  2. 数据表设计死板,只注重三范式,字段减省,很多需要展示的数据都要逐条查询,效率很差;

  3. 权限判断从低向高判断,写到第二个小功能就基本崩了;

  4. 涉及时间节点判断时,忽略了临界值的问题,对查询条件考量不够严谨;

  5. 日期查询时,php日期函数date('m')生成的是01,数据库字段类型为int,查询无效;

  6. 有一部分数据开始是用json字段存储的,后面涉及到计算,不管是拿出来还是存进去,需要做的判断都略麻烦;

解决的办法
  1. 按照层级命名,修改逻辑,可以正常读取后还是放弃了使用缓存;

  2. 在大佬指导下增加了冗余字段用于查询,三范式固然重要,逆范式也不可或缺;

  3. 权限判断改为自上至下,这样再增加权限层级低的角色也无需修改上层判断逻辑;

  4. 根据规则重新确定查询条件后,增加临界时间节点的判断;

  5. 月份数据定长2位,数据表字段改为char,但是感觉偏离初衷,int查询效率更高才做了冗余字段月份进行查询;

  6. 后来还是把json字段的数据剥离出来单独放到一张表中保存了;

项目中学习的
  1. 修改部分的同时要关注全局影响,项目接近结束时,修改某个在项目中看似毫不起眼功能的业务逻辑都可能影响到很多条数据的正确性,牵一发而动全身;

  2. 永远也不能相信前端传递过来的数据,很多自己写完代码看起来绝对不可能发生的错误,在测试或实际使用时的的确确的发生了。按照正确科学合理的流程代码都是能通过的,但是用户有时候是会瞎β操作的,限制越多,出错的概率就会越小,但总归会有遗漏;

  3. 所有修改都要有凭据,每次被问到某个具体功能的权限判断时,第一回答往往是:我去看下代码。很尴尬,在接手项目的时候就应该有意识将原型概述整理成自己的文档,每次修改都做好记录,这比看代码逻辑快捷方便的多;

  4. 脱离session、cookie之外,之前毫无概念的JWT验证;

  5. 准备工作越充分,实际上手写起来越轻松愉快;

不足之处

这个项目是最难啃的一个模块写完之后交到自己手上的,已经有现成的业务逻辑和数据表,我所做的是剩余模块功能的编写和后续需求修改,代码规范也很垃圾,有的地方会把复用查询写到模型里,有时候把DRY原则抛弃了,怎么顺手怎么写,同样的数据不同的地方用不同变量命名,同样的查询用不同的查询语句,还有就是是否命名新变量存放函数值也不很懂,比喻成搬砖就是别人建好了房子我会添砖加瓦,缺乏自己设计和打地基这种从0到1的对项目整体的把控能力,在后续的修改和维护中也犯了其他习惯之类的错误,好在有人指导,能从沟里把自己带出来。

其他

终于写完了,好开心,别人问到自己哪里哪里的时候会有掌控全局的感觉,发现bug的时候有种自己修的房子被人发现少块砖头的难受(╯﹏╰),编码能力上学会了使用闭包,框架的一些用法也更熟练了,但也是个弊端,脱离了框架感觉自己就玩不转了,对数据表的设计和查询优化有了初步认知,也仅仅是初步认知,自己写的东西查询效率感觉还是有很大改进空间,最主要的是学到了对整个项目各个模块之间数据联系的把控,不能看到哪里就只改哪里。

附上两篇写项目时看过的文章:
什么是JWT
当谈SQL优化时谈些什么

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值