報告！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分佈式等等。

往下一個階段都會寫總結，勉勵本身，發現不足，定製目標，謝謝。

若是有幫助，請關注此公衆號，點個贊。