1

从大学开始接触Web开发,到现在已经是第9个年头了,但是感觉自己才刚刚开始入门。特别是开发模式(这个称法待议),不同的公司不一样,团队结构,团队合作方式都有很大的区别。我虽然经历的公司不多,但是接触了一些,自然有些比较。今天主要分享一下morningstar的产品开发模式。

传统的产品开发

一个产品的上线,需要经历非常多的步骤,单就产品开发这个方面,主要可以分成几个块。不同的年代,方式也不同,分块的依据也各异。下面是我总结的传统的产品开发模式:

图片描述

这种模式非常清晰,特别是对于程序员而言,非常容易定位。一个程序员,是做哪一个产品,是前端还是后台还是数据库开发,都可以找到自己的位置。

而且这种开发模式有很多有点,比较适合敏捷开发。大公司小公司都在用,小公司可能只有一个产品,一个团队,大公司可以多个产品线,多个团队,团队之间有人员流动,但所有的研发人员都可以非常明确的用“在开发哪个产品,自己是哪个端”来给自己在公司里面定位。

早期的时候,前后端其实也分得不是很清楚,后端用PHP,顺带就使用MVC框架那一套,把HTML+CSS的部分全部完成了。比如你用PHP框架进行开发,完全是后端主导,因为所有的页面HTML模板全部是后端定义的。

随着前后端分离的思想出现之后,上面这种完全后端主导的局面也逐渐瓦解了,前后端分离是指前端和后端专注(甚至只)做一件事,所以在我写的《从web架构来认识nodejs》这篇文章里,就勾画了大致的新的前后端分工:

图片描述

中间通过Node将前端和后台完全分离。后端完全专注于数据和数据业务逻辑,前端则通过node实现界面和交互,对后端仅有数据接口依赖。

这种改变使得web开发从“CMS向APP”转变,以前的MVC更多的是CMS的思想,而现在的MVC更多的是APP思想。

Morningstar的产品开发思想

作为外企,Morningstar的产品架构都是在芝加哥完成的,深圳团队主要是在架构思想上进行具体的实现,老外的思想总比国内激进一些,国内PHP还盛行的时候,我们的产品仅留下Java和JavaScript两门语言。Java开发data api,而JavaScript实现剩下的全部产品开发。如果你关注我的微博,应该有发现我提到过这点。

昨天在rong给我们讲解了公司目前的产品研发的思想后,我觉得这可能是未来产品研发的趋势,特别是经过十多年发展之后,开发已经不再仅仅是横向的工具,而逐渐成为企业纵向的血液,不仅要控制成本,而且要保证产品群是公司想要的结果。于是,就有了下面的结构:

图片描述

和传统的产品开发有很大的不同,在这种模式下,一个程序员无法给自己在产品线上定位,程序员不知道自己在为哪一个产品开发(或者说程序员在为所有的产品做开发)。

在传统模式下,前后端分离,后端开发者调用数据库为前端提供api,但是往往基于某一个产品的特定需求,相当于定制。而现在data层的开发并不为产品服务,而直接为整体业务服务,data api不再从业务逻辑出发,而是以data point为目标。data api团队接到的需求绝对不是产品需求,而是非常明确的“需要哪些(数据)点,可以按照xx进行区间和步幅查询,可以按照xx排序,可以按照xx分组”类似这样的需求,它完全脱离了业务逻辑,开发者并不需要知道自己的开发具体是为哪一个产品服务,也不知道自己的api具体要实现什么业务逻辑,程序员只需要专注于算法和性能。

最大的不同莫过于capability这一层。因为公司现在也不知道怎么来定义这一层,所以目前暂时用capability称呼。这一层是开发者集中的一层,也就是前端开发(后端在data层)。这一层你可以看到,总体层面有一个framework,当然也不一定只有一个framework,可能有多个framework实现不同的逻辑,但总体上就是要有framework,用来装component,所有的功能都被制作为component,用户需要什么功能,就把component塞到framework里面去,打包好之后,就成了一个product,可以卖给客户。

实例说下:我们有一个产品,叫Asset Manager,是向基金经理提供资产管理分析的产品。我们还有一个产品,叫Wealth Manager,是向更高级别的用户提供资产管理者分析的产品。这两个产品的目的不同,前者是要让用户(基金经理)更好的管理资产和进行预测分析,而后者更多的想让用户(投资机构)挑选合适的基金(通过看这个基金经理的业绩来确定是否值得挑选),所以这两个产品的需求不同。但是虽然需求不同,可是有些方面,在数据呈现上是一样的,比如单支基金在某个时段的流入流出,这两个产品都可以查看这个情况,所以实际上它们使用同一个component,在类似的其他某些点上,也可以使用相同的component塞到不同的产品里面去。

所以,实际上,capability一层为product一层提供了原材料,或者叫“组件,模块”,product是对这些“模块”的组装。而这些component就是零件,它们可以被复用,甚至通过修改配置,来使得连接到不同的data api上,以适应更好的product。

这种开发模式的意义非常大,它相当于解放了所有开发者,让他们更专注,同时在公司层面,可以极大的降低成本,产品更加快速,可以说有多少种component的组合,就可以有多少个产品。

两种模式的比较

我在Morningstar开始的时候很迷茫,不知道自己到底是要做什么,而且component的开发有自己的一套规则,所以大部分时间都在研究这些规则,研究完规则之后,跟以前写前端没有什么差别,只不过还是不知道自己是在为哪一个产品服务。后来在理解这种模式之后,我就对自己的状况有了更多的了解。

那么这两种模式哪一种更好呢?答案当然是不确定,只能说“适合就好”。

1. 公司成长阶段

如果一个公司只有一个产品,刚开始创业,当然是传统模式更占优势,比如开发知乎的团队,为了让产品赶紧上线,迅速迭代,当然要开发团队自己拿主意。如果采用第二种模式,前端开发受到后端的制约,后端受到数据库的制约,component受到framework的制约,framework受到具体需求的制约,制约来制约去,消耗的就是时间。

但是当公司成长起来,到了一个特定的阶段的时候,产品就有可能这样去分。比如微信,把通讯录、公众号、朋友圈儿、支付看成component,那么整个微信就是framework。但是在腾讯公司这样一个大的环境里,仍然保持着传统的开发模式,很多资源重复开发,不知道会不会是制约腾讯的一个点。

2. 模块重用可能性

一个公司的产品虽然多,但是都不是同类产品,自然要将这些开发分开。比如淘宝和支付宝,不可能放在一起,但是它们底层的数据可以共享。比如QQ和腾讯视频,如果作为两个单独的产品,也不可能有什么地方可以重用。如果一个公司,做了一款电商产品,过了一点时间又做医疗产品,那也不能重用。

但是如果产品之间的模块重用性很大,就应该考虑新的开发模式。

Morningstar的所有产品之间具有非常大的相似性,产品界面几乎长一个样,但具体的细节却不同,不同的基金经理需要的数据不一样,所以得到的产品也不一样。这就非常适合使用这种新的开发模式。

3. 敏捷开发(团队)

敏捷开发的前提是,有一个非常强有力的团队,而团队意味着集中在某些具体的开发上面。但是敏捷开发一般都是针对产品,产品的需求、设计、测试、迭代,都要快。但是在Morningstar的这种模式下,根本无所谓敏捷不敏捷。

程序员所在的团队可能只有开发和测试,而没有设计,甚至连产品都没有。从公司层面讲,也不能以产品进行团队划分,比如腾讯,可以用一个游戏划分一个团队,但是在Morningstar,除了大产品模块的划分(比如桌面端产品,web端产品,其他业务产品),其实没有具体的产品团队,更多的是开发团队,而开发团队内部才划分到具体的产品线上。

总结

我只能从自己的感觉去理解,Morningstar作为核心技术架构在美国的公司,有很多技术上先进的地方是值得思考的,但是作为个人,开发者也要为自己的成长考虑。如果按照Morningstar的模式发展下去,不出几年,这种架构就会稳定下来,一个开发者很快会成为这种稳定结构中的一个节点,就像流水线上的工人,需要用自己熟练的操作,在规定的时间快速完成规定的动作。比如有一个新的component要做,实际上component的规则已经定好了,你必须先把这些框架性质的代码先写好,然后开始发挥,但是众所周知,这种发挥的空间并不算大,而且很有可能只是利用经验,而非学到东西。

但是作为公司层面,甚至作为社会协作层面,这种模式值得借鉴,它可以更好的降低开发成本,特别适合拥有数据资源的公司,像微博、腾讯、阿里这些公司,已经在数据服务上开始思考了。作为开发者,也可以在拿到相同报酬的情况下获得更多的休息时间,这或许是解决国内程序员加班问题的一条途径吧。而且有了这套模式,把众包模式具体化也是有想象空间的。


本文先发布在我的博客,欢迎到我的博客拍砖探讨
作者:@否子戈
微信:wwwtangshuangnet


否子戈
2.2k 声望143 粉丝

疯狂前端开发中……