背景
经常遇到一些朋友问我,现在要学什么技术,用怎样的路线来学习。我的建议是无论你现在学什么都是会过时的,所以不如学一些工作中用的着的技术。比如linux命令、intelij快捷键,工作中用spring就学spring。就这样。不用什么高大上学什么。而是实践出真知。通过学习和实践增加自己知识的深度,建立自己的知识网。
而工作中除了一些实现技术之外,很多其他的技术通常被忽略。比如习惯于产品经理将一切定义好了,自己照着实现就可以了。慢慢的多接触一些框架、中间件才发现。原来实现是其中最容易的步骤,原本很多交给产品经理做的设计却是很多中间件成功的核心。再后来,发现做什么比怎么做更重要。这时候才发现参加各种技术大会的意义。是要了解业界演进的方向。
今天我们就来一起探讨一下三个基本的就算产品经理不说自己也需要实现的技术功能。
前置校验
场景举例
想买一个东西A,加入购物车,为了凑单又买了很多其他的东西。刚好凑好满减。一遍暗自感叹自己太聪明了,一遍提交订单。这时候出来一个弹出框,提示说:「您选购的产品A已售完」。这时候的心情大概不是十个「你爷爷的」可以平复的。
解决方法
这个场景更好的一种实现方式是前置校验。如果产品已经售完,则在产品上标注一下,让这个产品不可购买。这就要用到前置校验了。这个技术很好实现:将原本的校验逻辑单独一个接口,在展示页和实际下单触发时都调用这个接口。最好能在展示页就将无效请求卡住,避免用户做无用功。
链接用户文档
场景举例
比如进入一个游戏网站,点入一款炫酷的游戏。我去,这个画面代入感太赞了,感觉自己就是身怀绝技的大侠。马上想出发升级打怪了。咦咦咦,怎么让人物前进呢?这时候是抓耳挠腮的自己琢磨,还是马上找朋友交流,还是问度娘?
解决方法
这个场景更好的一种实现方式是在游戏的一个区域链接用户文档。让用户希望得到指导的时候就看到了。当然,用户文档、QA文档、在线客服都是解决同一类问题。
聚合提示
场景举例
程序员除了事故之外最怕的是什么?是半夜惊魂的报警。最可怕的是一会儿一条停不下来。收这个频率的报警一晚上就不要睡了。
解决方法
这个场景更好的一种实现方式是聚合提示。如果一个同类消息很频繁,则按照一定的频率规则聚合后发送给用户。避免用户收到过多的骚扰。
这里的聚合提示可以指最简单的告警事件压缩来做。也可以先过滤不关心的事件进行降噪之后,利用人工智能无监督学习,结合自然语言处理NLP做聚类。简单来说就是可以根据场景和资源,可简单可复杂。
总结
在分布式系统的演进过程中,经历了CAP理论到BASE理论的一个转变。就是说因为一致性、可用性、分区容错三者不可兼得。通过权衡将系统设计为基本可用、软状态、最终一致性。这个演进说明很多时候各方面达到60分比完全不考虑其中一点把其他的做到极致会产生更大的价值。
如今在内容性产品这个赛道上,有人提出用户、内容、商业不可兼得。就是说内容性平台由于商业的影响,平均可用价值在降低(内容熵增)。比如一个公众号为了实现商业价值,点进去一篇认为可能有用的文章,实际上却看到了一篇广告。很多平台在内容和商业间做了权衡,在广告上稍微加些干货,类似于软广来实现最终价值的最大化。
通过这两个例子我说明的是:看到一些同学一味的追求高大上的技术而底层基础和产品意识并不过关。在当今社会中这种思维往往是不能将自己的价值实现最大化的。建议补齐短板,更均衡发展,每一步都发挥价值。