大学开始接触web开发已经是第九个年头了，但感觉自己才刚刚入门。尤其是开发模式（这个名字正在讨论中），不同的公司不同，团队结构和团队合作方式有很大的不同。虽然我经历的公司不多，但是接触过一些，自然也有一些比较。今天主要分享晨星的产品开发模式。传统产品开发一个产品要上线需要经过很多步骤。仅就产品开发而言，可以分为几个部分。时代不同，方法也不同，划分的依据也不同。以下是我总结的传统产品开发模型：这种模型非常清晰，尤其是对于程序员来说，非常容易定位。一个程序员不管做哪个产品，前端还是后端还是数据库开发，都能找到自己的定位。而且这种开发模式有很多优点，更适合敏捷开发。大公司和小公司都在使用它。一个小公司可能只有一个产品和一个团队。一个大公司可能有多个产品线和多个团队。团队之间有人员流动，但所有研发人员都能用的很清楚。开发什么产品，你是什么目的”来定位自己在公司的地位。在早期，前端和后端并没有明确区分。后端使用了PHP，顺便使用了MVC框架来完成HTML+CSS部分。比如你用PHP框架开发，那完全是后台主导的，因为所有的页面HTML模板都是后台定义的。随着前后端分离思想的出现，上述完全由后端主导的局面逐渐瓦解。前后端分离就是前后端专注（甚至只）做一件事，所以在我写的《从web架构来认识nodejs》这篇文章中，一个粗略的新前后端分工概述：前后端通过中间的Node完全分离。后端完全专注于数据和数据业务逻辑，而前端通过node实现接口和交互，只依赖后端的数据接口。这一变化让Web开发从“CMS到APP”转型。以前的MVC更多的是CMS的思想，现在的MVC更多的是APP的思想。Morningstar的产品开发思路是国外公司，Morningstar的产品架构是在芝加哥完成的。深圳团队主要贯彻架构思想。外国人的思想总是比国内激进。产品只剩下Java和JavaScript两种语言。Java开发数据api，而JavaScript实现所有其余的产品开发。如果你关注我的微博，你应该注意到我提到了这一点。昨天在融给我们讲解了公司目前的产品开发思路后，我觉得这可能是未来产品开发的趋势，尤其是经过十几年的发展，开发不再只是一个横向的工具，而逐渐成为一个企业对于垂直血脉，不仅要控制成本，还要保证产品群是企业想要的结果。因此，有如下结构：与传统的产品开发有很大区别。在这种模式下，程序员无法将自己定位在产品线上，程序员也不知道自己在开发哪个产品（或者说程序员是在开发所有产品）。传统模式下，前后端分离，由后端开发者调用数据库为前端提供API，但往往是基于某个产品的具体需求，即相当于定制。现在，数据层的开发不是为产品服务的，而是直接为整体业务服务的。数据API不再从业务逻辑出发，而是以数据点为目标。数据api团队收到的需求绝对不是产品需求，而是一个很明确的“需要什么（数据）点，可以按照xx查询范围和节奏，可以按xx排序，可以按xx分组"类似的需求，完全脱离了业务逻辑。开发人员不需要知道他们正在为哪个产品开发，也不需要知道他们的API需要实现什么业务逻辑。程序员只需要关注算法和性能。最大的区别是能力层。因为公司不知道这个层怎么定义，所以暂且称之为capability。这一层是开发人员集中的层，即前端开发（后端在数据层）。在这个层次上可以看到整体层次上有一个框架。当然，不一定只有一种框架。可能有多个框架来实现不同的逻辑，但总的来说，必须有一个框架来安装组件，并且所有的功能都涵盖了。做成一个组件，如果用户需要什么功能，就把组件塞进框架里，打包之后，就变成了一个产品，可以卖给客户。举个例子：我们有一个产品叫资产管家，它是一个给基金经理提供资产管理分析的产品。我们还有一个产品叫WealthManager，就是一个给上层用户提供资产管理者分析的产品。这两种产品的用途不同。前者是为了让用户（基金经理）更好地管理资产和进行预测分析，而后者更多是为了让用户（投资机构）选择合适的基金（通过看基金经理的业绩来判断是否值得）picking），所以这两种产品的需求是不一样的。但是，虽然要求不同，但在数据呈现上有些方面是相同的，比如某段时间单笔资金的流入流出情况。两种产品都可以检查这种情况，所以实际上它们使用的是同一个组件。在其他一些点上，同样的组件也可以用来填充不同的产品。所以，其实能力层为产品层提供原材料，或者说“组件、模块”，而产品就是这些“模块”的组装。而这些组件是零件，它们是可以复用的，甚至可以通过修改配置，连接到不同的数据API，适配更好的产品。这种发展模式意义重大。相当于解放了所有的开发者，让他们可以更加专注。同时，在公司层面，可以大大降低成本，让产品更快。可以说，组件的组合越多越好。有多少产品。两种模式的比较刚开始晨星的时候我很迷茫，不知道自己要做什么，而组件开发有自己的一套规则，所以我把大部分时间都花在了研究这些规则上。研究完规则，跟之前写前端没啥区别，但是还是不知道自己服务的是哪个产品。后来了解了这个规律后，才更加清楚自己的处境。那么这两种模式哪种更好呢？当然，答案是不确定的，只能说“合适”。1、公司的成长期。如果一家公司只有一种产品，刚开始创业，当然传统模式更占优势。比如知乎的开发团队必须自己做决定，才能快速上线产品，快速迭代。如果采用第二种模式，前端开发受后端约束，后端受数据库约束，组件受框架约束，框架受具体需求约束。限制来来去去，时间也在消耗。但是当公司成长到一定阶段，产品可能会这样划分。比如微信把通讯录、公众号、朋友圈、支付作为组件，那么整个微信就是框架。但是在腾讯这样的大环境下，依然保持着传统的开发模式，很多资源都是重复开发的。不知道会不会成为制约腾讯的一个点。2.模块复用的可能性虽然一个公司的产品很多，但是它们不是一类的，所以很自然的把这些开发分开。比如淘宝和支付宝不能放在一起，但是底层数据可以共享。比如QQ和腾讯视频如果是两个独立的产品，就没有复用的地方。如果一家公司做了一个电子商务产品，过一段时间再做一个医疗产品，它就不能被重复使用。但是如果产品之间有大量的模块复用，就要考虑新的开发模式了。所有晨星产品都非常相似。产品界面几乎相同，但具体细节有所不同。不同的基金经理需要不同的数据，因此得到的产品也不同。这非常适合使用这种新的开发模式。3、敏捷开发（团队）敏捷开发的前提是要有一个非常强大的团队，而团队就是专注于一些具体的开发。但是敏捷开发一般是针对产品的，产品需求、设计、测试、迭代都要快。但是在晨星这个模式下，你敏捷不敏捷都无所谓了。程序员的团队可能只有开发和测试，没有设计，甚至没有产品。从公司的角度来看，团队不能以产品来划分。比如腾讯可以用一款游戏来划分一个团队。没有具体的产品团队，更多的是开发团队，开发团队又分为具体的产品线。综上所述，我只能从自己的感受中了解到，Morningstar作为一家在美国拥有核心技术架构的公司，有很多技术先进的地方值得思考，但作为个人，开发者也必须考虑自身的成长.如果按照晨星模式发展，几年之内，这个结构就会稳定下来，一个开发者很快就会成为这个稳定结构中的一个节点，就像流水线上的工人，需要用自己熟练的操作，才能在规定的时间内迅速完成规定的动作。例如，有一个新组件要开发。实际上，组件的规则已经设置好了。你必须先写好这些框架属性的代码，然后才能开始玩。但是众所周知，这种玩法的空间并不算太大，而且很可能是用经验而不是学东西。但是作为公司层面，甚至作为社会协作层面，这种模式是值得学习的。可以更好的降低开发成本，特别适合有数据资源的公司。微博、腾讯、阿里等公司已经开始了数据服务。想了想。作为开发人员，同样的薪水也可以获得更多的休息时间。这或许是解决国内程序员加班问题的一种方式。而有了这种模式，众包模式的具体化就有了想象的空间。本文首发于本人博客，欢迎到本人博客讨论作者：@叫子戈微信：wwwtangshuangnet
