微信点餐的需求和技术演变
微信点餐的需求和技术演变
背景
先解释下什么是Hack版本，什么是Saas版本？
Hack版本就是指使用侵入的手段破解点菜机的各种信息，使得点菜机看起来就像是我们自己的一样。
Saas版本就是指做我们自己的点菜机，还要做成服务的
为什么要做Saas版本的微信点餐？
因为目前的hack版本面向未来开发导致现实问题很多，多到让微信点餐产品看不到未来，商户静悄悄的越来越少
微信点餐的业务需求
11个核心功能
- 微信线上点单
- 微信线上支付
- 点菜机线下点单（退菜）
- 点菜机线下支付
- 点菜机关台
- 支持优惠
- 支持库存
- 支持做法
- 支持转台
- 支持套餐
- 支持快餐
- 支持优惠券，储值，积分
1-6是一期内容，神通交接前已完成。7-10是二期内容，属于后续功能扩充。11是待完成功能，12是附加的会员管理方面的功能。
Hack版本
当初为什么立项，现在已不可考。但是微信点餐产品做出来终归是为了占据点餐市场，并且作为会员服务其中的一项增值服务。
Hack版本的问题
目前hack版本的微信点餐到底存在哪些问题？
常见问题
- 各种环境问题（软件没配置对，被杀毒软件杀了，点菜宝异常）等等导致的数据上传错误，缺失
- 打印机不出票
- CRM不能操作菜单
- 小程序下单超时、点菜宝链路异常等各种点餐失败原因
- 商家点菜机落后最新版本100多个版本
- 关台不正常，导致小程序看到没关的单
- 购物车没有清空，在不同清空下到底要不要清
- 该打折的没有打折，不该打折的打折了，重复打折
- 不支持带价格的做法，导致价格各种不对
- 小程序点的多规格的菜在点菜机上价格会被改掉为最小价格
- …(还有一百万个)
总之，消费者使用体验很差，就像我们去吃饭用小程序点餐一样，会喷人家做的怎么这么烂。商家使用体验很差，只要出一点问题，消费者就喊商家解决，商家有不明白，然后就上报，报多了就默默地撕掉了点餐码。运营人员和技术人员接到问题之后被商家一顿喷，还得老老实实的给排查解决问题，但是对于那种数据源头不属于自己的系统的奇怪性的概率问题，查起来真的很难受。不管对于消费者还是商户还是运营人员还是开发人员来说，完全没有用户体验。So：去你妈的微信点餐，真难用
主要问题
hack版本微信点餐凉凉的主要原因：
- 点菜机源头的任何结构改动都会导致整体不可用：例如美食专家的字段改动，导致读不到任何数据
- hack的方式使得整个win端的配置太过于复杂，导致没有CS或者技术参与，出了问题商家根本不知道怎么办
- hack的方式使得各种点菜机出了问题也都是找我们，而不是找点菜机厂商
- 各种不同版本的点菜机对于具体的菜不一定有唯一键，导致对于临时调价这种场景无法匹配到菜，结果老师出现各种价格不对的问题
基于事实基于约定面向未知
口号：我们不生产点菜机，我们只是点菜机的搬运工
那么之前是如何搬运的呢？此处有两个主要步骤：
- 打通点菜机：破解点菜机的数据库密码，了解点菜机的数据库结构，并且adapt到我们自己的数据格式
- 打通点菜协议：解密博立协议，通过点菜宝和串口/网口将点菜信息写入到点菜机
很容易看到，基于事实基于约定面向未知的产品设计本身就不是一个稳定的产品，只能当成一个实验室产品使用，但是最后却错误的上线到了生产。
目前的现状
- 已打通83款点菜机（hack点菜机密码、菜品图片、菜品增删改查、做法等等信息）
- 支持博立协议的所有点菜机点餐
因为面向未知，不确定因素导致维护成本很高。为了快速上线，新需求带来的新代码都嵌入到了老代码中，导致高耦合度，每一块看上去很恶心的代码都能看到和点餐相关的逻辑，所以后续就有拆分visit和stage的过程。
hack的方法
手持点菜宝通讯过程：
通讯过程
- 点菜宝和基站通讯是通过无线特定赫兹（433MHZ）；
- 基站和收银机计算机通讯可以通过串口或者网口方式；
通讯测试
硬测试：点菜宝和基站通讯上需要通过将基站拨码处于调试状态测试，通信是单向的，基站发送，点菜宝接收；
软测试：软测试是指将通信基站连接计算机，用“无线点菜机管理”软件对通信基站与点菜机进行测试，此时的测试是双向的，即正常使用模式。
通讯协议
点菜宝，基站，收银机计算机数据交换采用的协议通常叫：博立协议，但是博立协议非行业标准协议，会存在不同厂商根据自身情况对协议进行私有定制开发；
协议有三个指令：登陆，开台，点菜；点菜宝在使用前需要先在收银机计算机“无线点菜机管理””模块中勾选点菜宝编号进行诸如“菜品”，“桌台”等基础数据同步到点菜宝内；然后“登陆”，“开台”，“点菜”流程；
除了hack点菜宝的通讯过程，还需要hack点菜机本身数据库的链接方式以及用户名和密码。
基站设备图：
Saas版本
点菜机初始版本只支持在线点餐，不支持离线点餐，网络不好的就不上。也就是说就是为了微信点餐服务的。
系统结构
参见mindnode
待确认问题
兼容性问题
因为模式太多，需要考虑兼容性问题
- win端起新的后台管理项目
- 后端新项目不支持老版本老模式，如果还有老用户就慢慢过渡到新版本
- 不再有堂食菜品库，都是自定义菜单，在win端管理后台管理
- B端的菜单设计功能逐渐废弃
优惠和菜品的关系
目前是否参与优惠取决于菜品是否有参与优惠的字段discountable，即是否参与优惠是菜品的一个属性。具体的优惠折扣应该是所有参与优惠的菜的总价的打折，这个是商家临时决定的。
折扣值具体在哪边设置需要确认下
做法和菜品的关系
目前做法是在菜品里面加一个字段，显示这个菜有多少种做法。对于每一个菜都需要设置做法信息。
改为Saas之后，做法需要单独维护一个做法表，做法分类和菜品做关联（需要确认是和菜品关联还是和sku关联），避免各种重复录入
做法分类表和做法表的设计：
做法分类：做法分类Code + 做法分类name，例如 0100 + 甜度
做法：做法code + 做法name + 做法分类code，例如 AAAA + 七分甜 + 0100
其他平台
屏芯：使用ActiveMQ推送。同样会产生因为推送超时导致的重复下单，不知道有什么巧妙的办法可以解决重复下单的问题。但是也说明推送的方式是可行的