领导专门拉了个会批斗了我一番。大伙帮忙看下，我的设计思路很离谱么

一大早，技术 Leader 专门拉了个会把所有技术拉过来开会，没有指名道姓但是基本上主要就是批我。看来真把领导气坏了，hhhh

前情：
产品有个需求，我们开会对过，大概 1 前端 1 后端的小活动，具体为
在现有业务某个入口，根据一定条件展示优惠券。能领取优惠券的用户，发一下验证码，然后调用另一个团队领优惠券的接口。有部分黑名单用户不能领，还有些其他小限制，比如只能领一次，优惠券会过期之类的。

是一个低频活动，每天几千 PV 左右的入口展示量级这样。

我的思路：
Redis 里存黑名单用户，大概 1w 人，可以动态增删。
两张 Mysql 表

一张存优惠券，包括优惠券的名字，数量，金额，一些关联条件等等。
一张存领取记录，用户信息，优惠券 id ，时间，用来判断用户是不是领过。

写了大概一千字的设计文档，包含接口定义等等，预计 1 周开发时间吧，我觉得是个比较小的需求，产品的预期也是先简单做一下看看效果，毕竟量也不大。写完美滋滋发给领导，然后遭到（女）领导的狂喷：

我草你这啥啊设计的，完全不符合你的职级啊！
「什么东西都按需求白描，就不会有好的架构。」

「你现在设计的服务，最大的问题就是太沉浸在需求里了，不能高于需求，设计的太死了，自己给自己留的余地太少。」

「尽量要把每个能力都抽象出来，可配置，不然就又只能重构，设计阶段就是干这个事情的，如果只是需求 by 需求的做，随便找个外包搞就行了。」

我......
咱就是说，一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊。
这么一个小的验证性需求，一定要搞个巨复杂的系统出来吗。我们都做过太多无用的业务，最烦的就是过度设计。你设计的再完善最后也不可能满足产品所有需求，难不成啥需求都得做一套低代码平台出来么。

好的架构应当是随着业务的发展生长出来的不是么。

所以老板到底想要的是啥子呢？想满足用户的需求可真难啊。

yesterdaysun

2022-12-16 14:10:24 +08:00

我稍微尝试代入一下你领导的视角: 你这个设计太没有前瞻性了, 我见过太多"按需求白描"的设计了, 优惠券这种东西我太清楚了, 以后肯定要大改, 为啥不一次性弄好, 我们系统其它地方都是按照一定余量一定灵活度设计的, 你为啥不照着那些来, 这才不是什么"过度设计", 而是有前瞻性的规划, 现在那些人说试验性需求, 过两天立马加大力度要你改, 看你到时候怎么办
我也尝试代入一下你的视角: 产品都说是小需求了, 加两张表足够了, 反正就两张表, 出问题改起来也容易, 字段不多, 没什么复杂的东西, 需求来了改起来轻轻松松, 余量刚刚好, 反正产品也要迭代的, 我这是"敏捷"的做法

以上纯属 YY, 反正我看来大概是沟通问题, 你们并没有一些共识, 你可能看不惯系统其它地方的"过度设计", 这次尝试一下"刚刚好的设计", 然后被领导发现, 就被批了, 那可以就这个机会讨论一下, 到底其他人怎么看待"过度设计", 如果能说服别人最好, 最差也可以知道其他人到底是怎么想的, 是真的碰到过坑, 小心谨慎的做法, 还是纸上谈兵, 夸夸其谈, 这个时候也不必说服对方了, 做你该做的就好了, 可以迫于领导压力, 按她的做, 也可以吸收你觉得好的设计用上, 也可以尝试坚持自己的做法.

我一般不上来把人想的太坏, 先当他是个"理性人", 看看确实有没有一些道理, 当然不排除最坏的情况, 就是领导看你不爽, 如果最终你的结论是这个, 那就只有第 36 计了

vmoewill

2022-12-16 14:11:34 +08:00

他想得瑟就给他台阶下。

卡券微服务，有订单就再来个订单微服务，验证码通知啥的一个微服务。不要 mysql 全 mongo ，微服务全无状态，代码全用 etcd 锁，用 DDD 思想写，黑名单限制、ip 手机号、只能领 1 次多次各种各样的限制用策略模式封装下。这样基本就不是数据驱动了。

行了，充分的设计，开整吧，然后开发两周，部署一个月，devops 哭死 -。-！

yufeng0681

2022-12-16 14:55:31 +08:00

1 、这个故事听下来，就不是一个 20 30 人的小公司。应该是个 100 人的中型公司
2 、做了这么久业务，还没有一个营销平台，说明公司又不是特别的大，还在发展期
3 、女领导这么喷，也许就是 [苦秦久矣] ，运营类的定制需求老是层出不穷，烦不胜烦 [我推测的]
4 、如果不是 [苦秦久矣] ，就是第一次有运营需求，那其实运营那边也无法提炼出来更多的扩展性需求，那你的方案只要加上产品运营侧研讨过，这是一次临时试点，还没有到做运营平台的时间段的结论。就比较全面，表示你考虑过得全面，做到了深入业务需求和可能性。
4.1 、还是要结合你们的业务，把运营需求规划起来。做产品运营的没经验，可能多来几次需求，就会把你们带到坑里去。所以提前研究，运营类的平台应该怎么做，怎么借助开源的，有什么已有框架可利用的。毕竟运营类功能不是新鲜事物了，都搞了 10 几年，通过识别竞品的实现，你反向还能约束运营的天马行空，不切实际，任性定制。
5 、系统设计师里面有架构师和业务设计两种，架构师的水平确实高一个级别，因为他看得更远；业务设计师，确实大家都能做的。你多参加公司更高级别的产品策划，可能就会知道公司的远景。如果老被动等着产品推动你，那自己也不可能快快的升级，去到更高的岗位。

xiaotianhu

2022-12-16 15:09:01 +08:00

@yufeng0681
老哥说的是。
可我司好几万人。我职级对标阿里 p6 ，我认为就是个干活的吧，说架构师肯定谈不上。但是老板总要说，你已经是个高级开发了，应该 xxxx 了...

营销运营平台这种事儿，咱也不是第一天做头一次做了。讲真，后续的需求，如果真的想全面设计，就要有更高层面的通盘的信息。举个例子，我们 Team 有 10 个产品，5 个开发，她作为技术 Leader 当然知道所有业务后续的计划，哪块应该复用怎么发展，但我不知道啊。跟我对需求的就其中 1 个产品。

我也做过领导，带过十几个人，也做过决策。你得有信息，信息越全面才能做出越靠谱的决策。大厂里的信息权，信息层级，真的是把「阶层」跟「官僚」这种概念体现的淋漓尽致了。当然这是另一个话题了，不展开了

zzzzz001

2022-12-16 15:27:06 +08:00

系统的混乱并非业务本身之复杂，我们并不擅长处理『简单』

一群高智商青年在餐厅吃饭，餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉，而标识为胡椒粉的瓶子里装得却是盐，他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个空碟子。当他们叫来服务员，准备炫耀他们的天才想法时，只见服务员什么也没说，只是拿起盐瓶和胡椒粉瓶，互换了瓶盖……

‘复杂’总是伴随着光环，当我们解决一个复杂问题后，我们会得到更多人的肯定，向大家证明和展示自己的实力。而简单往往更‘暗淡’，如同上文提到的互换瓶盖，大家并不会因此认可服务生的能力，甚至觉得也没什么大不了。如此往复，让大家更青睐复杂，更远离简单。

今天刚看了一篇文章：
https://mp.weixin.qq.com/s/Rk49n_QgHKPpbSyDj-vvHQ

zzzzz001

2022-12-16 15:29:36 +08:00

不要轻易地离开技术领域的一线前沿，离开技术、放弃编码的决定很可能会像你高考之后放下的数学、生物、地理等知识那样，一旦放手，毕生就很难有机会再重新捡起来。

久而久之，你对代码、技术、产品状态与团队研发状态的理解，渐渐和团队成员产生了偏差错位，丧失了细节上给予指导的能力，丧失了专业问题上提出接地气解决方案的能力，只能在无法“Show me the code”短期难以校验对错的大战略方向提意见，在会议、流程及团队管理措施上下功夫，在职业经理人式的宣讲与汇报上寻找存在感，此刻，你便从团队的导师变成了管理者，最终你与团队的关系，从携手并肩奋斗的伙伴，完全演变成只能靠公司制度与管理职位的权力来维系雇佣关系。

是不是似曾相识？