项目问题记录,与反思

1.队列问题

唤醒营销问题:建立活动,当用户最后一次消费达到指定时间时,微信推送唤醒,并且发券
问题:代码写好后,进不了队列
本地调试不好调试,必须推到测试环境
出现问题的原因:
队列用的死循环方式实现的,
也就是说,如果代码有问题,就会卡死,队列堵塞
解决方法:加日志,测试代码完整性,

2.关于规则和逻辑的一些取舍问题

问题:建表字段问题
描述:需要在优惠券表添加一个是否叠加的字段,现在有一个其他类型的优惠券字段,isdiscount在这个优惠券类型中用不到。
我的思路是新建一个字段,isSuperposition
队友的思路是复用 isDiscount 防止优惠券表过于庞大;
其实这是逻辑与规则的一些取舍,无所谓对错,只不过站的角度不同,所以取舍不同。复用这个字段会使代码开发很快的进行,但是这样的开发模式,就回给后期带来一些麻烦,

我坚持的原因:

1.假如项目日渐庞大,我们会用字典表来约束数据库字段,形成规范。一词多用并不规范
2.词不达意
3.根据建表三大范式,字段是不可再分,具有原子性。

3.数据库字段的不合理:

历史遗留问题,没法修改,就这样吧;
粉丝表,粉丝Id:fensId;
其他表的粉丝id外键 fid
会员表,会员id:memberId;
其他表的会员id外键:vipId;

4.关于数据库字段的使用

问题 :用数字表明状态,类型时一定要注意
例如,是否关注公众号字段:1关注 ,0未关注 通常用来表明是否存在.0,1一般用来表明绝对否定或者绝对肯定
例如,类别 中信银行,农业银行,工商银行 ,这种不要用 0从1开始
字段的含义,一定要注意。
细节决定成败

5.bug修改,一定要有大局观

有大局观,考虑问题要全面,
思考做出的改变,会引起其它新的改变吗。
思考是否还有其他地方,也有相同的问题

6.订单类的接口注意事项

涉及到订单,或者支付的时候,一定要加日志,尤其是前后端分离,多小组合作的时候;
在哪加?
接受前端传过来的值的时候 ;
嗲用其他小组接口时,给的值,和对方返回的值;
这样就能快速定位错误;

公司倒闭....
此项目记录到此为止;

江兆辉博客
请先登录后发表评论
  • 最新评论
  • 总共0条评论