关于在疫情期间辅助社区和物业工作人员购买和发放蔬菜系统软件的一些设计思路

不知不觉在家里都关了一个多月了，作为一个普通人，在武汉疫情期间即使是在家待着心情还是挺焦急的。于是结合自己小区的实际情况，我决定用我的一些专业知识（程序员）来就“小区团菜较混乱”的问题，略尽一份绵力。

一、分析小区团菜现状

经前期观察发现小区团菜流程是这样的：

由社区、物业人员或志愿者（以下简称物业人员）联系好商家，获取商品套餐信息
物业人员简历相应的团菜微信群，或直接在现有的团菜微信群中发布菜品套餐信息供业主选择
物业人员发起团购接龙，有需要购买的业主在微信群内接龙自己的套餐订购信息和个人信息
物业人员在接龙结束后统计人数及购买情况，并发起收款
将所收集到的菜款付给商家，等待菜品配送
待菜配送到小区后，根据最终付款结果，物业人员通知已购菜业主分批次下楼领取已购菜品

流程是这么个流程没错，但是在实际操作上却问题不断。

首先，物业人员一开始仅通过微信群自带接龙工具进行报名接龙。该工具在百人群内的表现堪称“灾难”。当物业人员发布了菜品套餐信息并开始接龙时，往往会有几十上百人同一时间开始点击接龙，而该工具并没有并发控制，以至于每个人填写完接龙信息并发出来之后，往往会出现：顺序不一致、漏缺信息等问题。而且该工具每接龙一次，就会在群内自动发送一条包含有前人所有接龙信息的文字。所以在接龙开始后，往往短时间内群内会出现“信息风暴”，群内消息瞬间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上传的工作自然就是我来做了，不然这个系统应该是能不需要我干预就能完全自助运行的。

目前系统稳定地支持了一次物业团菜，果然没有人的菜再被冒领了~~ 后续有时间我再做一些小优化嘻嘻 (#^.^#)

（等完善一下，疫情结束后在开源吧）