从大学开始接触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的规则已经定好了，你必须先把这些框架性质的代码先写好，然后开始发挥，但是众所周知，这种发挥的空间并不算大，而且很有可能只是利用经验，而非学到东西。
但是作为公司层面，甚至作为社会协作层面，这种模式值得借鉴，它可以更好的降低开发成本，特别适合拥有数据资源的公司，像微博、腾讯、阿里这些公司，已经在数据服务上开始思考了。作为开发者，也可以在拿到相同报酬的情况下获得更多的休息时间，这或许是解决国内程序员加班问题的一条途径吧。而且有了这套模式，把众包模式具体化也是有想象空间的。
2016-09-06 4073 Morningstar, 开发模式
[…] Morningstar的产品开发模式 […]