微信点餐的需求和技术演变
先解释下什么是Hack版本,什么是Saas版本?
Hack版本就是指使用侵入的手段破解点菜机的各种信息,使得点菜机看起来就像是我们自己的一样。 Saas版本就是指做我们自己的点菜机,还要做成服务的
为什么要做Saas版本的微信点餐?
因为目前的hack版本面向未来开发导致现实问题很多,多到让微信点餐产品看不到未来,商户静悄悄的越来越少
11个核心功能
1-6是一期内容,神通交接前已完成。7-10是二期内容,属于后续功能扩充。11是待完成功能,12是附加的会员管理方面的功能。
当初为什么立项,现在已不可考。但是微信点餐产品做出来终归是为了占据点餐市场,并且作为会员服务其中的一项增值服务。
目前hack版本的微信点餐到底存在哪些问题?
总之,消费者使用体验很差,就像我们去吃饭用小程序点餐一样,会喷人家做的怎么这么烂。商家使用体验很差,只要出一点问题,消费者就喊商家解决,商家有不明白,然后就上报,报多了就默默地撕掉了点餐码。运营人员和技术人员接到问题之后被商家一顿喷,还得老老实实的给排查解决问题,但是对于那种数据源头不属于自己的系统的奇怪性的概率问题,查起来真的很难受。不管对于消费者还是商户还是运营人员还是开发人员来说,完全没有用户体验。So:去你妈的微信点餐,真难用
hack版本微信点餐凉凉的主要原因:
口号:我们不生产点菜机,我们只是点菜机的搬运工
那么之前是如何搬运的呢?此处有两个主要步骤:
很容易看到,基于事实基于约定面向未知的产品设计本身就不是一个稳定的产品,只能当成一个实验室产品使用,但是最后却错误的上线到了生产。
因为面向未知,不确定因素导致维护成本很高。为了快速上线,新需求带来的新代码都嵌入到了老代码中,导致高耦合度,每一块看上去很恶心的代码都能看到和点餐相关的逻辑,所以后续就有拆分visit和stage的过程。
手持点菜宝通讯过程:
除了hack点菜宝的通讯过程,还需要hack点菜机本身数据库的链接方式以及用户名和密码。
基站设备图:
点菜机初始版本只支持在线点餐,不支持离线点餐,网络不好的就不上。也就是说就是为了微信点餐服务的。
参见mindnode
因为模式太多,需要考虑兼容性问题
目前是否参与优惠取决于菜品是否有参与优惠的字段discountable,即是否参与优惠是菜品的一个属性。具体的优惠折扣应该是所有参与优惠的菜的总价的打折,这个是商家临时决定的。 折扣值具体在哪边设置需要确认下
目前做法是在菜品里面加一个字段,显示这个菜有多少种做法。对于每一个菜都需要设置做法信息。 改为Saas之后,做法需要单独维护一个做法表,做法分类和菜品做关联(需要确认是和菜品关联还是和sku关联),避免各种重复录入 做法分类表和做法表的设计: 做法分类:做法分类Code + 做法分类name,例如 0100 + 甜度 做法:做法code + 做法name + 做法分类code,例如 AAAA + 七分甜 + 0100
屏芯:使用ActiveMQ推送。同样会产生因为推送超时导致的重复下单,不知道有什么巧妙的办法可以解决重复下单的问题。但是也说明推送的方式是可行的