关于在疫情期间辅助社区和物业工作人员购买和发放蔬菜系统软件的一些设计思路
? ? 不知不覺在家里都關了一個多月了，作為一個普通人，在武漢疫情期間即使是在家待著心情還是挺焦急的。于是結合自己小區的實際情況，我決定用我的一些專業知識（程序員）來就“小區團菜較混亂”的問題，略盡一份綿力。
?
一、分析小區團菜現狀
? ? 經前期觀察發現小區團菜流程是這樣的：
? ? 流程是這么個流程沒錯，但是在實際操作上卻問題不斷。
? ? 首先，物業人員一開始僅通過微信群自帶接龍工具進行報名接龍。該工具在百人群內的表現堪稱“災難”。當物業人員發布了菜品套餐信息并開始接龍時，往往會有幾十上百人同一時間開始點擊接龍，而該工具并沒有并發控制，以至于每個人填寫完接龍信息并發出來之后，往往會出現：順序不一致、漏缺信息等問題。而且該工具每接龍一次，就會在群內自動發送一條包含有前人所有接龍信息的文字。所以在接龍開始后，往往短時間內群內會出現“信息風暴”，群內消息瞬間99+，大量重復內容的復制發送會瞬間淹沒群內正常發布的信息。
? ? 其次，鑒于上述工具所有人的團菜信息均在群內明文發送，故有個人信息泄露的隱患。這可能直接導致領菜時，你家的菜被人給冒領。
? ? 第三，每次接龍后，物業人員在統計、補漏、付款等工作環節均會耗費大量人力物力。前期我們小區物業團的3次菜，每次都需要物業人員花費2小時以上的時間去做報名統計。
? ? 第四，物業人員在菜品分發環節，受限于人力有限，每次發菜時都會出現個別業主菜被人冒領的事情。物業人員費時費力為大家團購一次菜，最后還要自己掏錢出來賠的鬧心情況時有出現。
?
二、如何改善
? ? 針對上述發現的問題，我們需要逐個解決。
? ? 最大的問題就是在疫情期間物業人員人手完全不夠。除開看守大門、垃圾轉運、消毒的工作人員之外，平時幫助我們團菜的物業人員只有2人，且她們還身兼數職，往往熬夜整理完群里的團菜信息后，第二天清早又要去大門口值班。工作十分辛苦但是效率較低。解決該問題的最好辦法就是招募志愿者，于是我報名參加了社區志愿者，幫忙物業人員處理團菜的一些事情。
? ? 對于上述的接龍工具問題，好在微信小程序中出現了不少已經開發完畢的成熟的接龍工具。在我的建議下，物業人員更換了一款帶有：導出報名表格、隱藏用戶信息、支持在線付款的微信小程序。每次開始團菜時，物業人員會將小程序鏈接發在群內，讓業主們在小程序上填寫自己的購菜信息，并完成付款。事后物業人員直接導出表格即可完成團購統計。在發放蔬菜時，根據導出表格發放。
?
三、意外情況
? ? 按照以上措施操作，理論上來說是不應該出錯的，但是在上周團菜時，依舊出現了蔬菜分發的問題 —— 又有幾位業主反饋說自家的菜被人冒領了！
? ? 事后大家一起總結問題時發現問題可能就出在“人”上。
? ? 那次團菜小區內共有124人參與團購，而物業人員僅在一張A4大小的紙上打印出了所有業主的購買信息，在分發時，密密麻麻的文字可能讓物業人員看串了行。其次，因臨時有事，中途換了一位阿姨過來幫忙發菜，但是她卻沒有按照要求通過核對領菜人的手機號碼發菜，而是僅核對了領菜人姓名。但是根據群內訂購信息公示表，領菜人的姓名是大家都可以看到的公開信息。第三就是可能因為人性的“貪”，拿了說沒有拿到。然后白吃蔬菜不給錢。
?
四、改進方案2.0
? ? 誠然，在如此高強度的工作下，物業人員難免會有疏漏，特別是應對密密麻麻的數據時，看花眼也是很可能出現的事情。作為常年和電腦打交道的人，我自然而然地想到：對于這種根據特定條件發放物資這種不用用腦子變通的事情，用電腦來做肯定要比人更合適。于是在現有情況的基礎上，我開始考慮在盡量不增加業主和物業人員工作量的情況下，針對訂購蔬菜的核發流程做一些優化設計，旨在利用機器解決問題。
? ? 發菜流程設計如下：
? ? 考慮到下批團購菜也即將分發，上述流程圖僅為一個簡易實現思路。于是我花了一下午時間大致完成了符合上述流程的系統開發。
? ? 服務端采用Springboot Web技術，配合MySQL數據庫快速開發完成相應的數據庫表設計與服務端接口。安卓App采用Android Studio自帶的Bottom Navigation Activity模板先直接生成了一個App框架，然后后續具體功能再自己完善。
?
?
五、技術細節
? ? 服務端數據庫設計上，考慮到原始數據來源為導出的excel表格，而表格上傳可能會因為種種原因有多次上傳的情況。這里默認把每次上傳的excel數據都會創建為一張新的數據庫表，每次默認激活的為最新生成的數據庫表。這里我選擇MyBatis作為ORM框架，并編寫SQL語句動態創建表
<update id="createNewTable" parameterType="java.lang.String">CREATE TABLE ${tableName} (`id` int NOT NULL AUTO_INCREMENT ,`order_id` int NULL ,`wechat_name` varchar(50) NULL ,`real_name` varchar(50) NULL ,`phone_no` varchar(11) NULL ,`commodity` varchar(255) NULL ,`sign_up_time` varchar(20) NULL ,<!---1：未付款;0：未領取;1：已領取-->`status` int(1) NOT NULL DEFAULT -1,serial_number int(12) NOT NULL DEFAULT 0,update_time varchar(20) NULL ,PRIMARY KEY (`id`));</update>? ? 為了效率，服務端自助生成二維碼的功能并沒有自己利用依賴包生成，而是使用在線生成二維碼接口API實現的該功能。
? ? 同樣為了保證效率，安卓端也直接使用了大量的開源組件：
- Sweet Alert Dialog
- 一個優化過后的基于ZXing的二維碼掃描器
個人開發的部分主要在于使用OKHTTP3與服務器進行接口數據通信，使用Google GSON進行JSON解析。
?
六、界面樣式
? ? 為了適配移動端，服務端的自助二維碼生成頁面采用了CSS3的自適應樣式布局
?
? ? 而安卓端這邊，因為受到Google官方模板和好看的Sweet Alert Dialog的加成，所以長相還過得去~ (#^.^#)
自己沒啥時間整ListView樣式了，所以就簡單做了下布局。大概就長這樣吧~? ^_^ ~
?
?
? ? 最后把服務端掛在阿里云上跑著就行了。因為我們小區物業的工作人員電腦操作不太熟，所以excel上傳的工作自然就是我來做了，不然這個系統應該是能不需要我干預就能完全自助運行的。
? ? 目前系統穩定地支持了一次物業團菜，果然沒有人的菜再被冒領了~~? 后續有時間我再做一些小優化嘻嘻 (#^.^#)
?
（等完善一下，疫情結束后在開源吧）
總結
以上是生活随笔為你收集整理的关于在疫情期间辅助社区和物业工作人员购买和发放蔬菜系统软件的一些设计思路的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【转】MAPI over HTTP协议
- 下一篇： MAC中LateX出字体问题