• • 項目背景
  • 項目需求
    • 后臺管理功能
    • 用戶功能
    • 頁面展示
  • 項目信息
    • 開發語言
    • 數據庫
  • 項目構想
    • 獲取幸運用戶
    • 用戶答題
  • 項目反思
    • 項目進度的安排
    • 團隊合作溝通方面
    • 項目的構建
    • 技術
    • 本地開發和上線的模式區別

---

項目背景

該項目主要是用來給學校啦啦隊進行投票，并結合當下比較火的在線答題而產生一款應用，因為我們的主要用戶流量來自于微信公眾號，所以該產品結合了微信公眾號實現了相應的功能

---

項目需求

后臺管理功能

• 實現啦啦隊伍信息的上傳
• 實現對于題目的增刪改查
• 實現文件（視頻，圖片信息）的上傳

用戶功能

• 給對應的啦啦隊留言，給留言點贊。不可重復點贊
• 每人每天可答五十道題目，根據正確的答題數目給啦啦隊投票
  
  • 答題時間為每天早晨的8：00-當天晚上8：00
  • 答題非一次性答完所有題目
  • 每道題目的思考時間為10秒鐘
• 可以同時給多個隊伍投票，投票成功后返回啦啦隊所在戰隊的最新里程數
• 隊所在戰隊最新的票數

頁面展示

• 啟動頁面展示產品slogan和當天數據統計

  • 每天下午五點以前顯示產品slogan
  • 每天下午顯示當天數據統計，格式為：當天答題數目為：xx,超過xx%的用戶； 當天獲得的助力數為：xx,超過xx%的用戶；當天為啦啦隊增加的助力數為：xx,超過xx%的用戶。

• 首頁展示各個啦啦隊的首頁宣傳圖片，口號和介紹

  • 要求每次進入頁面時，啦啦隊伍順序隨機
  • 點擊某個啦啦隊伍的首頁宣傳圖，進入這個啦啦隊伍的詳情頁
• 詳情頁包含啦啦隊伍的輪播圖，宣傳視頻，啦啦隊員的個人照片和留言信息
  
  • 點擊啦啦隊員的照片，放大啦啦隊員的照片，并顯示啦啦隊員的姓名和個人簡介
  • 頁面下端顯示啦啦隊留言信息

• 戰隊排行榜頁顯示各個戰隊目前的分數和戰隊所具有的啦啦隊

  • 根據戰隊的分數進行降序排列

• 個人信息頁面顯示個人的微信頭像，昵稱，自己所具有的分數，自己的助力歷史

  • 助力歷史顯示自己總共為該戰隊的投票數，和當前該戰隊目前所具有的分數
• 個人答題榜頁面顯示根據答題正確數量最多的前十名用戶，和當天的三名幸運用戶。
  
  • 每晚八點，系統自動根據當天答題的情況隨機抽取三名幸運用戶

---

項目信息

開發語言

• JAVA

數據庫

• MySQL作為主要的數據庫，Redis作為緩存數據庫

---

項目構想

因為整個項目主要分為前臺用戶和后臺管理，因為這次項目在上線過程中主要出現的問題主要集中在幾個點，所以我將著重的介紹一下這些“坑”

獲取幸運用戶

其實剛開始看到這個需求的時候，自己還是比較蒙的，因為他涉及到一個在某一個特定的時間點就需要程序自啟，剛開始自己的想法是通過多線程的方式去自啟（如何通過多線程的方式去自啟方法我將在java開發微信公眾號部分將進行介紹和應用），后來查了相關資料發現，其實用listener實現該方法的自啟才是最好的選擇，在服務器部署的時候計算一個當前部署時間與晚上發布幸運用戶的時間差，然后程序根據該時間差進行自啟，并在一天以后再次自啟。進入循環，從而實現了該功能

用戶答題

這個地方會有多出涉及到一個Redis的數據類型的使用，如果對于Redis的使用還不是很清楚的同學可以看看我的另一篇博客Redis基本的數據類型和常用命令看看相關的介紹

• 獲取題目
  
  • 這個部分的需求主要是產品希望用戶每天只能答50道題目，每十題增加一個難度，而且用戶不是一次性答完50道題，用戶可以隨時退出，下次接著答。所以在這方面考慮到了對于數據庫的壓力，所以我采取的方法是在用戶當天第一次進入答題時，一次性取出50道題目，題目按照難度排序，然后將題目寫入Redis的HashMap中，并將所有答案單獨存放在一個HashMap中，并設置有效時間為一天，每次根據用戶已經答題的數目作為key，查詢新的題目。當用戶非當天第一次請求時，先判斷用戶當天的答題數目是否已經超過50題。

• 獲取正確答案（即判斷用否回答正確）

  • 這一部分的需要注意的點就比較多：
    1.我們需要判斷用戶傳回來的questionId是否在當天給他抽取出來的50道題目中；
    2.我們需要防止用戶對同一道題進行重復的發請求（同一個數據重復發送50次，從而達到50題全對），所以我們需要對用戶進行一個答過的questionId記錄（這個地方我采用的是Redis的集合方式），再根據questionId獲取正確答案之前在集合中先查詢判斷一下，如果已經答過（在獲取題目時，會避免同一用戶在當天答到相同的題目），則直接作為錯誤請求處理；
    4.我們還需要對用戶今日的一個答題數目進行判斷（這個地方我采用的是Redis的String類型，其實完全也可以通過計算該用戶的答題歷史的集合元素個數實現）
    5.根據前端傳回來的questionId查詢正確的答案返回給前端，判斷用戶是否正確，并將答題記錄在mysql中*

• 為啦啦隊投票

  • 這個需要注意的地方主要是一個點：
    1.大家應該對于Redis有一個初步的了解那就是Redis其實是一個單線程的，所以，我們在對于判斷前端傳來的數據（因為可以同時投多個隊伍，所以需要對用戶所投的所有票數相加然后判斷是否具有足夠的投票數進行投票），就可以啟動一個Redis的單線對于投票進行控制，防止同一個用戶在上一次投票還未處理完，下一次請求就發起（例如：一個用戶具有20票，他投了20票，當他第一次請求后，判斷他是有足夠的票數，他又發起第二次請求，如果第一次請求還未完成扣除票數的操作，那么該用戶的第二次請求還是會判斷為成功）

項目反思

項目進度的安排

這一部分自己出現的問題主要是對于項目進度安排的不合理所造成的。因為產品那邊提出相應的需求后，自己并沒有思考一些需求是否具有其實際的使用價值。例如題目上傳的部分，完全可以使用Excel導入的方法實現，完全沒有必要開發相應的接口，其次自己前期主要花太多時間點著重于后臺管理的開發，而忽略了這個項目其實真正的核心功能點在于用戶提供答題為啦啦隊助力，而不是后臺管理界面的開發，所以在最后產品快要上線的前期，自己的核心功能點還尚未實現。所以建議各位在實際的項目開發方面，最好先權衡利弊，考慮一個項目的核心功能點在于什么地方

團隊合作溝通方面

在這次項目的開發過程中，以及后來的測試中，出現最突出的問題就是和團隊的溝通的不足。導致在后期的接口調試過程中出現了很多因為溝通不足而造成的錯誤，浪費了很多不必要的時間，所以建議各位在后面的項目開發方面加強和團隊的溝通，畢竟一個項目不是一個人的事，好的溝通或許真的是成功的一半。

項目的構建

在這個地方，我覺得需要提醒的是我們在開發的過程中，盡量做到模塊化的開發，盡量解耦和降耦，否則在后期的代碼調試和需求的調整方面，將會十分的麻煩，自己就在這個項目上吃了很大的虧，浪費了很多不必要的時間，同時也可以提高代碼后期的復用率；同時，對于數據庫的設計方面，也可以根據實際項目的需求，合理的進行設計。沒有必要完全按照范式的要求去設計，必要的時候可以進行一些字段的冗余，從而降低查詢的難度和查詢的時間；當然，還有對于項目的優化應該是建立在需求能夠實現的基礎上進行的，如果需求不能夠實現，那么優化就是無稽之談。這個地方，自己前期就花了太多的時間在答題的優化和對數據庫壓力方面，但是實際的項目并發沒有想象中的那么大，所以完全可以等項目的基礎功能實現之后再進行優化。

技術

這個其實也是限制自己這次項目的最大因素吧，因為個人的能力原因，對于一些設計模式的學習不足，在整個項目中，幾乎看不到什么比較具有亮點的地方，更多的像在堆需求，同時，這個項目的過程中，出現的最大的問題，是自己在網上借鑒了一部分關于redis連接池的代碼，這段代碼在本地測試時沒有任何的問題，但在項目上線后就立馬出現了很大的問題，當時也沒有即使的檢測出來，導致項目的停滯，也是整個項目出現bug的最主要的因素。所以希望各位今后在開發的過程，如果涉及到了借鑒他人的代碼，一定要做足相應的測試。同時建議各位多看看別人優秀的代碼，從而提高自己的實際開發能力

本地開發和上線的模式區別

其實對于大多數開發僅限于本地測試的同學，其實難以區分自己本地測試和需要上線的項目的區別，其實在做這個項目之前，自在開發這個項目之前也沒有很深刻的印象，但當本地測試通過，但在真正當項目部署服務器后，才回發現原來有很多的地方的不同，所以建議各位在開發前期，就準備好本地測試的配置和上線配置的切換，以及各位其實沒有機會得到鍛煉的小伙伴可以嘗試去買一個服務器，自己嘗試部署，來體驗其中的不同。

以上就是自己對于這次項目所有的看法和新的體會，能力有限，尚存在諸多不足，望各位批評指正。

掃碼關注作者個人技術公眾號,有關技術問題后臺回復即可，不定期將有學習資源分享

總結

以上是生活随笔為你收集整理的基于微信公众号的答题投票系统——项目开发心得体会记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。