一大早，技术 Leader 专门拉了个会把所有技术拉过来开会，没有指名道姓但是基本上主要就是批我。看来真把领导气坏了，hhhh
前情：
产品有个需求，我们开会对过，大概 1 前端 1 后端的小活动，具体为
在现有业务某个入口，根据一定条件展示优惠券。能领取优惠券的用户，发一下验证码，然后调用另一个团队领优惠券的接口。有部分黑名单用户不能领，还有些其他小限制，比如只能领一次，优惠券会过期之类的。
是一个低频活动，每天几千 PV 左右的入口展示量级这样。
我的思路：
Redis 里存黑名单用户，大概 1w 人，可以动态增删。
两张 Mysql 表
一张存优惠券，包括优惠券的名字，数量，金额，一些关联条件等等。
一张存领取记录，用户信息，优惠券 id ，时间，用来判断用户是不是领过。
写了大概一千字的设计文档，包含接口定义等等，预计 1 周开发时间吧，我觉得是个比较小的需求，产品的预期也是先简单做一下看看效果，毕竟量也不大。写完美滋滋发给领导，然后遭到（女）领导的狂喷：
我草你这啥啊设计的，完全不符合你的职级啊！
「什么东西都按需求白描，就不会有好的架构。」
「你现在设计的服务，最大的问题就是太沉浸在需求里了，不能高于需求，设计的太死了，自己给自己留的余地太少。」
「尽量要把每个能力都抽象出来，可配置，不然就又只能重构，设计阶段就是干这个事情的，如果只是需求 by 需求的做，随便找个外包搞就行了。」
我......
咱就是说，一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊。
这么一个小的验证性需求，一定要搞个巨复杂的系统出来吗。我们都做过太多无用的业务，最烦的就是过度设计。你设计的再完善最后也不可能满足产品所有需求，难不成啥需求都得做一套低代码平台出来么。
好的架构应当是随着业务的发展生长出来的不是么。
所以老板到底想要的是啥子呢？想满足用户的需求可真难啊。
前情：
产品有个需求，我们开会对过，大概 1 前端 1 后端的小活动，具体为
在现有业务某个入口，根据一定条件展示优惠券。能领取优惠券的用户，发一下验证码，然后调用另一个团队领优惠券的接口。有部分黑名单用户不能领，还有些其他小限制，比如只能领一次，优惠券会过期之类的。
是一个低频活动，每天几千 PV 左右的入口展示量级这样。
我的思路：
Redis 里存黑名单用户，大概 1w 人，可以动态增删。
两张 Mysql 表
一张存优惠券，包括优惠券的名字，数量，金额，一些关联条件等等。
一张存领取记录，用户信息，优惠券 id ，时间，用来判断用户是不是领过。
写了大概一千字的设计文档，包含接口定义等等，预计 1 周开发时间吧，我觉得是个比较小的需求，产品的预期也是先简单做一下看看效果，毕竟量也不大。写完美滋滋发给领导，然后遭到（女）领导的狂喷：
我草你这啥啊设计的，完全不符合你的职级啊！
「什么东西都按需求白描，就不会有好的架构。」
「你现在设计的服务，最大的问题就是太沉浸在需求里了，不能高于需求，设计的太死了，自己给自己留的余地太少。」
「尽量要把每个能力都抽象出来，可配置，不然就又只能重构，设计阶段就是干这个事情的，如果只是需求 by 需求的做，随便找个外包搞就行了。」
我......
咱就是说，一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊。
这么一个小的验证性需求，一定要搞个巨复杂的系统出来吗。我们都做过太多无用的业务，最烦的就是过度设计。你设计的再完善最后也不可能满足产品所有需求，难不成啥需求都得做一套低代码平台出来么。
好的架构应当是随着业务的发展生长出来的不是么。
所以老板到底想要的是啥子呢？想满足用户的需求可真难啊。
44
Select Language