xufei

这个很好啊

@sunOpar 我觉得平级state不是问题，本身你这些页面之间没什么关系的话，最好是分开。如果要做一定程度的复用，可以从业务实体的角度出发，但最好还是跟state隔离开

这篇刚出来的时候，我看了一遍，好像也没抓住文中的重点。昨晚 @dead-horse 贴了一篇内网的东西给我看，今天又看了一遍，貌似明白了。 楼上 @jincdream 说的那段，跟本文尝试要解决的问题不在一个层面。本文里面写的，应该确实是侧重应用脚手架和构建工具，为什么会跟fis有侧重点的差异，我的理解，是因为各自面临的应用场景不同。 如果你的产品前端形态存在大量的模板，很少有前端的组件化体系，“构建”本身要做的事情并不会特别复杂，那大部分问题确实是资源的管理，fis可能更适合。 但蚂蚁的场景是不一样的，蚂蚁面临的一大堆项目，前端的形态是客户端部分偏重，组件化复杂度高，没有什么模板的东西，各项目之间存在不少配置上的差异，也有很多构建过程要做的事情，而且还面临跟发布体系的集成，整个是产品开发和发布链条的其中一块环节。 在一个产品启动的时候，需要有脚手架给业务项目提供默认配置，给它一些可选的配置项，到底给哪些，不给哪些，是这篇要尝试解决的问题，要把不同类型的需求尽量覆盖到，并且还要把配置项抽象起来，收敛起来，避免各项目随意写自定义配置，导致后续升级之类的问题。 蚂蚁这边的项目特点是，业务项目的选型和构建发布过程都是受到强管控的，始终有一个中心化的大平台在支撑整件事情，所以一定不会期望一个业务项目的配置项和发布过程很特立独行，除非它在业务上就有其不可避免的特殊性。即使有那种情况，也会在平台这边提供选项，而不是放任其自己搞。

@yozman 光用getter是解决不了数据层问题的，比如说，一些异步更新怎么推到你的getter内部？要么就得用类似ng1那种暴力方式。 https://github.com/xufei/blog/issues/42

@Brooooooklyn 有个问题你考虑下： 比如说，业务上，有些东西有上下级关联，比如，某个子任务产生了变更，所以你会把它所属的任务的流也产生一个更新，实际上这个地方不一定合适。 比如说，界面上有一个任务详情，一个任务卡片，这两者对子任务变更的响应是没有必要一样的，详情要响应，但卡片未必要，所以我觉得，是不是sdk内部不聚合流，把这些丢给业务来聚合？比如说聚合出两种task$，一种包含了子任务之类的信息，另外一种没有。后者可以直接是sdk里面export出来的，前者由业务（详情界面）再自己合并子任务的流。

@Saviio 昨天我说的这个问题，确实是 @Brooooooklyn 说的意思…… 现在这样是避免了，因为每个东西的查询约束不再一样了，之前是没有分开的，只要从SDK出去，都是一样的，而实际业务上会有对同一个实体不一样结构的订阅需求

@chemdemo 开发阶段用尽可能小的粒度，发布时候合并

@fouber 我之前也对构建系统的看法也类似，但以这段时间在苏宁看到的情况来说，这个构建系统太难建成，主要是部门划分和模块划分的不一致性。命名空间式的构建，要求的是互相之间没有交叉，理想状况是一个树形下去，但一交叉就完蛋了，要不然是命名空间的粒度过小，要不然是命名空间横跨部门，给构建带来很大麻烦。 @lifesinger 阿里的细节情况我不清楚，但估计是很类似的，所以我才逐渐明白sea里面有些细节的用意。之前没想到这些情况，没能理解为什么非要这么搞。以我之前公司的情况来说，是有大部门，也有统一的架构组，而且大部分产品是纯AJAX交互，所以连非静态模板的问题都很少有。 但是在网购型系统里，很可能顶部的购物车、支付模块等，不是来自本系统，而是来自其他业务部门，这些东西却非要集成在一个页面里，它们的公共项就很难处理。所以我理解阿里把模块拆得这么碎，然后用看上去很怪异的方式，在nginx那边搞combiner来合并，然后也正是为此，可能js会有乱序，必须晚期依赖。

@lifesinger > @fouber 你真应该来阿里看看呀，很多时候，场景决定方案。FIS 很适合百度的场景，但拿到阿里的场景下，依旧还有许多路要走。 那个，阿里好像刚收购了uc，你们已经在一家了……

> 很多人觉得模块化开发的工程意义是复用，我不太认可这种看法，在我看来，模块化开发的最大价值应该是分治，是分治，分治！（重说三）。 这句极其赞同