生鲜商城小程序项目总结
生鲜商城小程序项目总结
1.项目需求
实现B2B的生鲜商城小程序，具有商品展示、加入购物车、提交订单、微信支付、推送微信模版消息等基本购物流程，还包括登陆注册、信息审核、个人中心等辅助功能。
2.项目排期
因为有类似功能的小程序代码可供参考，且有3个人不同程度的参与开发，实际开发时间为3周，后续维护了3周二期就移交其他人员了
3.值得一提的技术点
因为之前有开发过大大小小3个小程序，对于小程序的基础使用都比较熟悉了，开发流程和提审流程也有经验，这次的收获，更多的是在实现特定业务时一些实现方案，和公司其他fe,rd,qa配合的磨合（来新公司的第一个项目）
点击查看详细代码
4.最后
- 接口文档自己写有点爽
因为rd正忙于其他工作，接口文档是自己编写的，感觉前端对界面上需要哪些数据、什么格式的数据显示起来更友好，更了解些，自己想要什么格式就写什么～当然前提是要遵循功能单一原则（一个接口完成一个功能）、尽量数据平铺代替嵌套，其他就是跟rd商量是否后端可行了
- 复用别人的代码要慎重
拿到初版mrd发现需求和一个已有项目十分相似，以为只是细节改动，就想复用之前的代码，但是UI和终版mrd出来后发现，其实UI和逻辑大大小小细节点都需要修改，说不上是省力还是费时了==
优点: 见贤思齐焉，见不贤而内自省也
读别人的代码，了解同一个功能，别人的实现思路和自己的区别，比较谁的更优
缺点：缝缝补补改造的东西，时常暗藏着小bug，还有一些冗余无用的代码，开始时没有删干净，后来就不记得是否有用而不敢删了
- 注释是个好东西
后续其他组接手这个项目，因为自己注释写的比较少，目测给其他fe小伙伴带来了很mmp的体验哈哈～有些bug需要紧急处理，来找我解决一下，自己猛然一看也会有点想不起具体的业务逻辑，所以还是开发时就顺手写点注释啦，不要留下个todo让人一脸懵逼
- 上线后不要随意接修改需求
之前的公司对于稳定性的要求没有特别严苛，所以修改都是比较随意的，产品提出一个需求，或者自己发现一个bug，就随时修改，自己手工测试一下就推上线了，发现bug再hotfix…那对于稳定性要求比较高的项目呢，应该先把线上版本回滚到稳定版本，再hotfix修复、找qa同学测试，再上线是比较稳妥的流程了。上线后，一个看似无伤大雅的小修改，事实证明，很可能产出一堆大大小小的bug，还是要尽量避免草草修改上线了，否则要更认真的确认影响范围
欢迎大家体验一下啦～人人都是bug质检员哈哈