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

一、分析小区团菜现状

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

  1. 由社区、物业人员或志愿者（以下简称物业人员）联系好商家，获取商品套餐信息
  2. 物业人员简历相应的团菜微信群，或直接在现有的团菜微信群中发布菜品套餐信息供业主选择
  3. 物业人员发起团购接龙，有需要购买的业主在微信群内接龙自己的套餐订购信息和个人信息
  4. 物业人员在接龙结束后统计人数及购买情况，并发起收款
  5. 将所收集到的菜款付给商家，等待菜品配送
  6. 待菜配送到小区后，根据最终付款结果，物业人员通知已购菜业主分批次下楼领取已购菜品
    ? ? 流程是这么个流程没错，但是在实际操作上却问题不断。

? ? 首先，物业人员一开始仅通过微信群自带接龙工具进行报名接龙。该工具在百人群内的表现堪称“灾难”。当物业人员发布了菜品套餐信息并开始接龙时，往往会有几十上百人同一时间开始点击接龙，而该工具并没有并发控制，以至于每个人填写完接龙信息并发出来之后，往往会出现：顺序不一致、漏缺信息等问题。而且该工具每接龙一次，就会在群内自动发送一条包含有前人所有接龙信息的文字。所以在接龙开始后，往往短时间内群内会出现“信息风暴”，群内消息瞬间99+，大量重复内容的复制发送会瞬间淹没群内正常发布的信息。

? ? 其次，鉴于上述工具所有人的团菜信息均在群内明文发送，故有个人信息泄露的隐患。这可能直接导致领菜时，你家的菜被人给冒领。

? ? 第三，每次接龙后，物业人员在统计、补漏、付款等工作环节均会耗费大量人力物力。前期我们小区物业团的3次菜，每次都需要物业人员花费2小时以上的时间去做报名统计。

? ? 第四，物业人员在菜品分发环节，受限于人力有限，每次发菜时都会出现个别业主菜被人冒领的事情。物业人员费时费力为大家团购一次菜，最后还要自己掏钱出来赔的闹心情况时有出现。

二、如何改善

? ? 针对上述发现的问题，我们需要逐个解决。

? ? 最大的问题就是在疫情期间物业人员人手完全不够。除开看守大门、垃圾转运、消毒的工作人员之外，平时帮助我们团菜的物业人员只有2人，且她们还身兼数职，往往熬夜整理完群里的团菜信息后，第二天清早又要去大门口值班。工作十分辛苦但是效率较低。解决该问题的最好办法就是招募志愿者，于是我报名参加了社区志愿者，帮忙物业人员处理团菜的一些事情。

? ? 对于上述的接龙工具问题，好在微信小程序中出现了不少已经开发完毕的成熟的接龙工具。在我的建议下，物业人员更换了一款带有：导出报名表格、隐藏用户信息、支持在线付款的微信小程序。每次开始团菜时，物业人员会将小程序链接发在群内，让业主们在小程序上填写自己的购菜信息，并完成付款。事后物业人员直接导出表格即可完成团购统计。在发放蔬菜时，根据导出表格发放。

三、意外情况

? ? 按照以上措施操作，理论上来说是不应该出错的，但是在上周团菜时，依旧出现了蔬菜分发的问题 —— 又有几位业主反馈说自家的菜被人冒领了！

? ? 事后大家一起总结问题时发现问题可能就出在“人”上。

? ? 那次团菜小区内共有124人参与团购，而物业人员仅在一张A4大小的纸上打印出了所有业主的购买信息，在分发时，密密麻麻的文字可能让物业人员看串了行。其次，因临时有事，中途换了一位阿姨过来帮忙发菜，但是她却没有按照要求通过核对领菜人的手机号码发菜，而是仅核对了领菜人姓名。但是根据群内订购信息公示表，领菜人的姓名是大家都可以看到的公开信息。第三就是可能因为人性的“贪”，拿了说没有拿到。然后白吃蔬菜不给钱。

四、改进方案2.0

? ? 诚然，在如此高强度的工作下，物业人员难免会有疏漏，特别是应对密密麻麻的数据时，看花眼也是很可能出现的事情。作为常年和电脑打交道的人，我自然而然地想到：对于这种根据特定条件发放物资这种不用用脑子变通的事情，用电脑来做肯定要比人更合适。于是在现有情况的基础上，我开始考虑在尽量不增加业主和物业人员工作量的情况下，针对订购蔬菜的核发流程做一些优化设计，旨在利用机器解决问题。

? ? 发菜流程设计如下：

发菜流程设计

? ? 考虑到下批团购菜也即将分发，上述流程图仅为一个简易实现思路。于是我花了一下午时间大致完成了符合上述流程的系统开发。

? ? 服务端采用Springboot Web技术，配合MySQL数据库快速开发完成相应的数据库表设计与服务端接口。安卓App采用Android Studio自带的Bottom Navigation Activity模板先直接生成了一个App框架，然后后续具体功能再自己完善。
安卓1

五、技术细节

? ? 服务端数据库设计上，考虑到原始数据来源为导出的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实现的该功能。

? ? 同样为了保证效率，安卓端也直接使用了大量的开源组件：

个人开发的部分主要在于使用OKHTTP3与服务器进行接口数据通信，使用Google GSON进行JSON解析。

六、界面样式

? ? 为了适配移动端，服务端的自助二维码生成页面采用了CSS3的自适应样式布局

自助生成二维码页面图
自助生成二维码页面移动端适配图

? ? 而安卓端这边，因为有Google官方模板和好看的Sweet Alert Dialog的加成，所以长相还过得去~ (#.#)

自己没啥时间整ListView样式了，所以就简单做了下布局。大概就长这样吧~? _ ~

安卓App UI图

? ? ? ? 最后把服务端挂在阿里云上跑着就行了。因为我们小区物业的工作人员电脑操作不太熟，所以excel上传的工作自然就是我来做了，不然这个系统应该是能不需要我干预就能完全自助运行的。

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

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

赏

摸鱼癌晚期患者