程序员一般分两种:搞中间件或者基础架构的,搞业务架构开发业务系统的。
搞中间件基础架构的
这种程序员一般被认为是技术更好一些,会深入研究一些基础技术,技术深度更深一些。
比如自建CDN,多云互备,长连接系统,五大中间件,linux内核开发,k8s平台等。
搞业务系统的
这种程序员是一个公司更大部分程序员的角色,大部分公司的程序员的大部分工作都是业务系统的开发。
这种程序员一般的要求是需要对自己的业务系统的业务有足够的了解的,只有足够的了解才能更好的内聚或模块化自己系统代码。同时更好的评审需求,让系统的架构设计具有面向未来业务发展的扩展能力。
比如营销系统,订单系统,商品系统,用户系统等。
很多程序员对于业务的理解很不屑,或者认为pm的需求太简单,所以对于理解业务的标准也比较低。当然大部分中小公司其实也没有多少业务可言,也就变成了大家所谓的业务开发就是CRUD的编码了。
那么究竟什么样的业务理解算是理解业务呢?
我们以商品系统为例简单讲讲。
很多电商系统都有商品中心的概念,商品对外建模可能是一个物理上的商品或者虚拟商品。商品中心,顾名思义,主要负责商品业务,我把它形容为电商业务的”基石“。
下面我们分别通过两条电商核心链路来认识一下商品业务:
搞商品中心很重要的两个名词就是SPU和SKU。
SPU
SPU 的英文全称是 Standard Product Unit,也有人说是 Standard Property Union(标准属性集合)。
不过,SPU 是和产品紧密关联的,称之为 Standard Product Unit 更准确, 即:标准产品单元,标准属性集合更形象。
SPU 是一组可复用、易检索的标准化信息的集合。该集合描述了一个“产品”的特性。SPU 是商品信息聚合的最小单位。
SPU 的组成一般是关键属性+商品属性+普通属性,不包含销售属性。
SKU
SKU 的英文全称是 Stock Keeping Unit,即库存基本单元。SKU 基本上是销售属性+价格+库存构成。
影响库存和价格的属性就是销售属性。
类目体系
类目就是商品分类,是商品信息的一种结构化描述,目的是为了管理、导购。目前商品包含类目:
类目属性
根据经营品类的不同,每个品类对应的属性也不同,定义为“类目属性” 。
如:SC类品类独有的属性有品牌、重量、产地 等,餐饮类品类独有的属性有菜系、烹饪手法、原材料等。这样任何品类都可以有任何属性。
比如:
分类方式又可分为 (后台类目、前台类目) ,分为三类类目(前台、后台、店内),其中店内类目由商家自行维护;后台类目由平台维护,是一份标准的数据集合。
后台类目:
商家可以进行售卖商品属性设置:
以美团外卖展示为例:
既然有这么多属性,和类目, 经过演进和抽象那么就产生了属性模板库。
“后台类目”与“属性”(属性与属性值)通过“属性模板”建立关联关系,一个属性模板可以关联多个后台类目,以此来实现可配置化,由平台统一维护。
在商品平台,维护了 比如:蛋糕甜点模板、小吃模板、主食粉面类模板、外国菜品模板、非中式菜、汤羹模板等。
上面看到的各种吃的,都划分到餐饮模板分类,包含了(美食,甜品,鲜花,医药健康,生活超市)。
主要是的特点:SPU、SKU为核心内容, 美食、甜点品类有“DNA属性”,主要是在这一个分类模板。
除此以外, 还有 SC ,药品,这些分类模板。
商品小视频
在商品展现纬度,为丰富不同常用的产品表现力,我们引入了商品小视频的概念:
商品标签
比如:菜品“西红柿炒鸡蛋”和“西湖牛肉羹”的标签如下:
上面只是整个商品中心的冰山一角,如果想做好商品中心还是需要研发人员对于整个行业对于商品业务有一定的了解的。
业务团队,特别是平台性质的业务团队在招聘人员时除了考察面试者本身技术能力外,还需要关心是否有相关方向研发经验或背景经验,这样可以较快的进入状态。如果一个程序员工作5年+,如果业务能力不过关和技术能力不过关是一样的。
所以多掌握某一个方向上的业务,深入某一个场景业务能力也是程序员面试时的一个加分项,程序员面试永远不是简单的看看技术能力。
很多公司提供的业务可能比较简单,但这样应该不是你无法在某个业务深度了解的接口,把自己当作PM,当作运营在技术之外再锻炼一条腿吧。