报告！7至8月中旬项目总结！

阅读本文约“5.8分钟”

---

序章

7月至8月中旬一直在忙公司新项目，这也是我第一次做技术领队的项目，从面试开始就一直在阅读有关技术团队管理有关的书籍，本文将简述此项目的总结，从设计到编码实现到上线测试用户反馈等方面，篇幅略长，建议收藏。

当然，这是期间也可能有更好的技术实现方案，希望各位朋友看后提出自己的建议，MySelf自当摸索了解，吸收消化，谢谢。

---

前言

这是一个基于小程序的电商类项目，前端一人，UI一人，后台兼项目技术总控一人，小弟不才，负责了最后一项，具体原因是公司内部......

人员也是由我亲自面试，因为3至6月自己负责设计完成了一整个类共享的小程序（后续相关推文介绍），所以对于小程序还算一点了解，仅在于功能实现与开发上的了解吧，对于UI，我一向是比较重视的，无论你的技术多好，产品对于用户没有吸引力那么一切都无从说起。

前端面试：小程序类MVC开发模式（model层js）

UI面试：产品核心理解、用户体验为主、功能核心突出

---

项目数据库设计

这个在面试阶段就开始设计了，项目是图书类电商，所以与商品差不多，主要是ISBN这块，对于数据库设计主要遵循范式，不要存在不必要的多表关联，数据读写逻辑清晰，CRUD便捷，由于上一项目的基础，所以我这次的设计也是比较熟练，当然还是存在一点缺点，类似一些推荐模块、积分商城、优惠券等的设计可能是没有经验，总感觉设计的不是很好。

对于数据库相关的具体，后期会推出一个系列，实际的践行，这里不是重点。

---

后台架构设计

上个项目SSM后，对于配置上的一些重复工作，让我这次直接选择SpringBoot，且它对于Java Web的功能都很好的便捷集成了，数据库操作工具选择JPA，缓存涉及登录Token、搜索引擎关键字，我选择大众品牌Redis，消息队列Kafka配合ElasticSearch搭建搜索引擎，数据库选择MYSQL，现在很少用Oracle。由于项目较赶，所以后台的管理界面使用Freemarker模板，确实比较方便。支付使用微信的SDK，小程序所以仅使用微信支付。对于日志系统，由于公司决定，所以仅做了基本的日志输出到对应文件，定期备份，没有做可视化模块，后期再上线，

大致项目架构图，没有画的很详细。

---

逐步分解：一

对于后台实现而言，如果你要写对应的Api文档给前端对接，那是一种相当耗时的事情，那么你可以选择SwaggerUI，一个小小的插件，可以减少你对文档花的时间，如下图，api开头的就是对应小程序的RESTFui API，fb开头的是后台管理界面的Freemarker模板生成页面。

逐步分解：二

首先是后台管理界面，你要与上线后的操作人员沟通，一般会有原型文档，对于产品与模块有上线下线，类似本项目的一个功能：阅读推荐，需要选择推荐的图书与编辑对应的文案还有作者、时间等信息，它也是需要上下线的，且对于图书的信息，只录入一次，库存或其他模块，需要唯一ID去对应获取信息即可。

VO的重要性，View Object，即排行版需要的数据信息仅仅是封面、书名、借阅人数、金额等，但是图书信息Entity是由这本图书的全部信息，我们需要定义一个对应的VO对象，针对排行版去给前端对应的数据，不要把全部信息都给前端，这是一种准则！且可能后台的属性名，与前端要读取的JSON参数名不一样，你可以使用@JsonProperty去与前端统一。

逐步分解：三

登录校验，Aspect切面处理，后台管理是一个禁区，所以需要Token的校验，除了登录、登出URL，其他URL都需要去校验Token的有效性，Token存放于Redis中，时效性是半小时，开发时可以设置长一点。

小程序也有对应的登录校验，app.js初始化小程序时，进行token校验，不存在就使用code来后台生成一个token，并保存用户的OpenId（SessionId），之后每次请求Token都放在Header中。

SpringBoot对于Redis、Kafka、ElasticSearch等其实都有默认支持，这一点是一个福音。

统一异常、Constants常量包、Utils、SDK包等这里就不一一介绍了。

逐步分解：四

搜素引擎ElasticSearch与Kafka的搭建，大致简介一下，图书数据入库（新增时）或更新，ElasticSearch中也有新增对应的图书信息，参数根据业务而定，图书下架时，ElasticSearch中进行移除，但是每次图书新增需要同步去执行ElasticSearch的操作，是一件存在隐患的事情，那么我们可以使用Kafka消息队列，让ElasticSearch去消费Kafka中的消息，去除同步的隐患。

ELasticSearch还能快速实现Search-as-your-type，保存关键字，定义返回关键字的个数，定义优先级别等。（后期因部分原因未上线）

在搜索中，还加了历史搜索，这个存在Redis中，一个Set，不重复且长度为7，即最多为7条历史搜索记录，会自动迭代上去。

逐步分解：五

对于用户信息，是比较重要的，押金、订单、快递信息等都是需要重复测试，不过这里主要是业务实现了，就不细说。

那么我们说说前端吧，我对前端实现的要求，H5模块，小程序有Template，即一些模块可以抽取，重复的样式抽取后使用双向数据绑定填充，js块则是MVC，算是这么说吧，多定义一层model进行数据的请求操作，原js层引入model（ES6的类操作），去调用model的数据请求方法，获取到的数据重新转给View层。

逐步分解：六

优化，数据懒加载，缓存使用等，这里涉及的比较多，那一个较容易理解的解释，排行版的数据是最多的，如果一次性加载完，那么用户需要等待10几秒不止，这个是绝对不允许的，那么我们可以一次加载10条，当用户下拉到底部时，再向服务器请求10条，这样可以提高用户体验，服务器接口也能提高工作效率，那么如果用户重新回到排行榜页面，那么我们又要再加载一次，其实这是没有意义的，我们可以使用小程序本地缓存，加载过的数据都放到缓存里面，当用户重新进入页面时，之前加载过的直接去缓存里面拿，不需要再次请求api，即如果用户之前已经看了100条数据，那么重新回来页面会直接显示100条，速度非常快，这样减少了服务器的不必要请求。

这里的缓存设置，再用户每次重新进入时，会重置，即每一次缓存里的数据是当前的最新数据。

拿出产品看看

一直说了那么多，也要让你们体验一下才行呀，一个借书平台，省去买书烦恼，不是广告，大家可以看看实现效果，当然项目较赶存在部分bug，见谅。（扫码了解，下单更好，哈哈哈）

对于技术，我还有很多进步空间，对于人员管理更甚。

结尾

本次项目总结到此结束，还有不足，将慢慢填充，如访问量瓶颈、数据读写瓶颈等，Tomcat横向扩展、Redis分布式等等。

往下一个阶段都会写总结，勉励自己，发现不足，定制目标，谢谢。

如果有帮助，请关注此公众号，点个赞。