深入分析Web应用程序前端的组件化

基本思路

1. 为什么要做组件化？

无论前端也好，后端也好，都是整个软件体系的一部分。软件产品也是产品，它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的，在产品目标确定的情况下，成本有两个途径来优化：减少部署成本，提高开发效率。

减少部署成本的方面，业界研究得非常多，比如近几年很流行的“去IOE”，就是很典型的，从一些费用较高的高性能产品迁移到开源的易替换的产品集群，又比如使用Linux + Mono来部署.net应用，避开Windows Server的费用。

提高开发效率这方面，业界研究得更多，主要途径有两点：加快开发速度，减少变更代价。怎样才能加快开发速度呢？如果我们的开发不是重新造轮子，而是每一次做新产品都可以利用已有的东西，那就会好很多。怎样才能减少变更代价呢？如果我们能够理清模块之间的关系，合理分层，每次变更只需要修改其中某个部分，甚至不需要修改代码，仅仅是改变配置就可以，那就更好了。

我们先不看软件行业，来看一下制造行业，比如汽车制造业，他们是怎么造汽车的呢？造汽车之前，先设计，把整个汽车分解为不同部件，比如轮子，引擎，车门，座椅等等，分别生产，最后再组装，所以它的制造过程可以较快。如果一辆汽车轮胎被扎破了，需要送去维修，维修的人也没有在每个地方都修一下，而是只把轮胎拆下来修修就好了，这个轮胎要是实在坏得厉害，就干脆换上个新的，整个过程不需要很多时间。

席德梅尔出过一款很不错的游戏，叫做《文明》（Civilization），在第三代里面，有一项科技研究成功之后，会让工人工作效率加倍，这项科技的名字就叫做：可替换部件（Replacement Parts）。所以，软件行业也应当引入可替换的部件，一般称为组件。

2. 早期的前端怎么做组件化的？

在服务端，我们有很多组件化的途径，像J2EE的Beans就是一种。组件建造完成之后，需要引入一些机制来让它们可配置，比如说，工作流引擎，规则引擎，这些引擎用配置的方式组织最基础的组件，把它们串联为业务流程。不管使用什么技术、什么语言，服务端的组件化思路基本没有本质差别，大家是有共识的，具体会有服务、流程、规则、模型等几个层次。

早期展示层基本以静态为主，服务端把界面生成好，浏览器去拿来展示，所以这个时期，有代码控制的东西几乎全在服务端，有分层的，也有不分的。如果做了分层，大致结构就是下图这样：

这个图里，JSP（或者其他什么P，为了举例方便，本文中相关的服务端技术都用Java系的来表示）响应浏览器端的请求，把HTML生成出来，跟相关的JavaScript和CSS一起拿出去展示。注意这里的关键，浏览器端对界面的形态和相关业务逻辑基本都没有控制权，属于别人给什么就展示什么，想要什么要先提申请的尴尬局面。

这个时期的Web开发，前端的逻辑是基本可忽略的，所以前端组件化方式大同小异，无论是ASP还是JSP还是其他什么P，都可以自定义标签，把HTML代码和行间逻辑打包成一个标签，然后使用者直接放置在想要的地方，就可以了。

在这一时代，所谓的组件化，基本都是taglib这样的思路，把某一块界面包括它的业务逻辑一起打成一个端到端的组件，整个非常独立，直接一大块从界面到逻辑都有，而且逻辑基本上都是在服务端控制，大致结构如下图所示。

3. SPA时代，出现了新问题

自从Web2.0逐渐流行，Web前端已经不再是纯展示了，它逐渐把以前在C/S里面做的一些东西做到B/S里面来，比如说Google和微软的在线Office，这种复杂度的Web应用如果还用传统那种方式做组件化，很显然是行不通的。

我们看看之前这种组件化的方式，本质是什么？是展现层跟业务逻辑层的隔离，后端在处理业务逻辑，前端纯展现。如果现在还这么划分，就变成了前端有界面和逻辑，后端也有逻辑，这就比较乱了。我们知道，纯逻辑的分层组件化还是比较容易的，任何逻辑如果跟展现混起来，就比较麻烦了，所以我们要把分层的点往前推，推到也能把单独的展现层剥离出来。

如下图所示，因为实际上HTML、CSS、JavaScript这些都逐渐静态化，所以不再需要把它们放在应用服务器上了，我们可以把它们放在专门的高性能静态服务器上，再进一步发展，就可以是CDN（Content Delivery Network，内容分发网络）。前端跟后端的通信，基本都是通过AJAX来，也会有一些其他的比如WebSocket之类，总之尽量少刷新了。

在这张图里面可以看到，真正的前端已经形成了，它跟应用服务器之间形成了天然的隔离，所以也能够很独立地进行一些发展演进。

现在很多Web程序在往SPA（单页面程序，Single Page Application）的方向发展，这类系统通常比较类似传统的C/S程序，交互过程比较复杂，因此它的开发过程也会遇到一些困难。

那为什么大家要做SPA呢？它有很多明显的好处，最核心的优势就是高效。这个高效体现在两个方面：一是对于用户来说，这种方式做出来的东西体验较好，类似传统桌面程序，对于那些需要频繁操作的行业用户，有很大优势。二是运行的效率较高，之前集成一些菜单功能，可能要用iframe的方式引入，但每个iframe要独立引入一些公共文件，服务器文件传输的压力较大，还要初始化自己的一套内存环境，比较浪费，互相之间也不太方便通信，一般要通过postMessage之类的方式去交互。

有了SPA之后，比如一块界面，就可以是一个HTML片段，用AJAX去加载过来处理之后放到界面上。如果有逻辑的JavaScript代码，也可以用require之类的异步加载机制去运行时加载，整体的思路是比较好的。

很多人说，就以这样的需求，用jQuery再加一个异步js加载框架，不是很足够了吗？这两个东西用得好的话，也是能够解决一些问题的，但它们处理的并不是最关键的事情。在Web体系中，展现层是很天然的，因为就是HTML和CSS，如果只从文件隔离的角度，也可以做出一种划分的方式，逻辑放在单独的js文件里，html内部尽量不写js，这就是之前比较主流的前端代码划分方式。

刚才我们提到，SPA开发的过程中会遇到一些困难，这些困难是因为复杂度大为提升，导致了一些问题，有人把这些困难归结为纯界面的复杂度，比如说，控件更复杂了之类，没有这么简单。问题在于什么呢？我打个比方：我们在电脑上开两个资源管理器窗口，浏览到同一个目录，在一个目录里把某个文件删了，你猜猜另外一个里面会不会刷新？

毫无疑问，也会刷新，但是你看看你用的Web页面，如果把整个复杂系统整合成单页的，能保证对一个数据的更新就实时反馈到所有用它的地方吗？怎么做，是不是很头疼？代码组织的复杂度大为提高，所以需要做一些架构方面的提升。

4. 架构的变更

提到架构，我们通常会往设计模式上想。在著名的《设计模式》一书中，刚开始就讲了一种典型的处理客户端开发的场景，那就是MVC。

传统的MVC理念我们并不陌生，因为有Struts，所以在Web领域也有比较经典的MVC架构，这里面的V，就负责了整个前端的渲染，而且是服务端的渲染，也就是输出HTML。如下图所示：

在SPA时代，这已经不合适了，所以浏览器端形成了自己的MVC等层次，这里的V已经变成客户端渲染了，通常会使用一些客户端的HTML模版去实现，而模型和控制器，也相应地在浏览器端形成了。

我们有很多这个层面的框架，比如Backbone，Knockout，Avalon，Angular等，采用了不同的设计思想，有的是MVC，有的是MVP，有的是MVVM，各有其特点。

以Angular为例，它推荐使用双向绑定去实现视图和模型的关联，这么一来，如果不同视图绑定在同一模型上，就解决了刚才所说的问题。而模型本身也通过某种机制，跟其他的逻辑模块进行协作。

这种方式就是依赖注入。依赖注入的核心理念就是通过配置来实例化所依赖的组件。使用这种模式来设计软件架构，会牺牲一些性能，在跟踪调试的便利性等方面也会有所损失，但换来的是无与伦比的松耦合和可替代性。

比如说，这些组件就可以单独测试，然后在用的时候随手引入，毫无压力。对于从事某一领域的企业来说，光这一条就足以吸引他在上面大量投入，把所有不常变动领域模型的业务代码都用此类办法维护起来，这是一种财富。

5. MV*框架的基本原理

如果我们来设计Angular这么一个前端框架，应当如何入手呢？很显然，逻辑的控制必须使用JavaScript，一个框架，最本质的事情在于它的逻辑处理方式。

我们的界面为什么可以多姿多彩？因为有HTML和CSS，注意到这两种东西都是配置式的写法，参照后端的依赖注入，如果把这两者视为跟Spring框架中一些XML等同的配置文件，思路就豁然开朗了。

与后端不同的是，充当前端逻辑工具的JavaScript不能做入口，必须挂在HTML里才能运行，所以出现了一个怪异的状况：逻辑要先挂在配置文件（HTML）上，先由另外的容器（浏览器或者Hybird的壳）把配置文件加载起来，然后才能从某个入口开始执行逻辑。好消息是，过了这一步，逻辑层就开始大放异彩了。

从这个时候开始，框架就启动了，它要做哪些事情呢？

初始化自身（bootstrap）

异步加载可能尚未引入的JavaScript代码（require）

解析定义在HTML上的规则（template parser）

实例化模型（scope）

创建模型和DOM的关联关系（binding, injection）

这些是主线流程，还有一些支线，比如：

解析url的search字符串，恢复状态（route）

加载HTML部件模板（template url）

部件模板和模型的关联（binding）

6. 如何做组件化

6.1. HTML的组件化

SPA的一个典型特征就是部分加载，界面的部件化也是其中比较重要的一环。界面片段在动态请求得到之后，借助模版引擎之类的技术，经过某种转换，放置到主界面相应的地方。所以，从这个角度来看，HTML的组件化非常容易理解，那就是界面的片段化和模板化。

6.2. JavaScript的组件化

JavaScript这个部分有好几个发展阶段。

早期的共享文件，把公共功能的代码提出出来，多个页面共用

动态引用，消灭全局变量

在某些框架上进一步划分，比如Angular里面又分为provider，service，factory，controller

JavaScript组件化的目标是什么呢，是清晰的职责，松耦合，便于单元测试和重复利用。这里的松耦合不仅体现在js代码之间，也体现在js跟DOM之间的关系，所以像Angular这样的框架会有directive的概念，把DOM操作限制到这类代码中，其他任何js代码不操作DOM。

如上图所示，总的原则是先分层次，层内再作切分。这么做的话，不再存在之前那种端到端组件了，使用起来没有原先那么方便，但在另外很多方面比较好。

6.3. CSS的组件化

这方面，业界也有很多探索，比如LESS，SASS，Stylus等。为什么CSS也要做组件化呢？传统的CSS是一种扁平的文本结构，变更成本较高，比如说想要把结构从松散改紧凑，需要改动很多。如果把实际使用的CSS只当作输出结果，而另外有一种适合变更的方式当作中间过程，这就好多了。比如说，我们把一些东西定义成变量，每个细节元素使用这些变量，当需要整体变更的时候，只需修改这些变量然后重新生成一下就可以了。

以上，我们讨论了大致的Web前端开发的组件化思路，后续将阐述组件化之后的协作过程和管控机制。

管控平台

1. HTML片段

我们为什么要管理HTML片段？因为有界面要用它们，当这些片段多了之后，需要有个地方来管理起来，可以检索、预览它们，还能看到大致描述。

这应该是整个环节中一个相对很简单的东西，照理说，有目录结构，然后剩下的就是单个的HTML片段文件了，这就可以解决存储和检索的问题了，但我们还要考虑更多。

已有的HTML片段，如何被使用呢？这肯定是一种类似include的方式，通过某种特殊标签（不管是前端还是后端的方式）把这些片段引用进来，这时候就有了第一个问题：

假设有界面A和界面B同时引用了片段C，在某个开发人员修改片段C内容的时候，他如何得知将会影响到界面A和B呢？一个比较勉强的方式是全项目查找，但这在很多情况下是不够的。

如果我们的HTML片段是作为独立的公共库存在的，它已经不能通过项目内查找去解决这一问题了，因为不管A还是B，只要他不处于片段C的项目空间，就无从追寻。

这时候很多人会问两个问题：

跨项目的界面片段重用，意义在哪里？

如果我们的产品是针对一个小领域，它的复杂度根本不需要划分多个项目部分来协作完成。设想场景是面对很大的行业，各项目都是子产品，将来可能是其中若干个联合部署，这时候，保持其中的一致性是非常重要的。比如我们有个基本配置界面，在多个子产品中都要用，如果各自开发一个，其操作风格很可能就是不一致的，给人的印象就是不专业。所以会需要把常见的界面片段都归集起来，供业务方挑选使用。

修改C，只提供说明，但是不通知A和B，不实时更新他们的版本，然后自行决定怎样升级，如何？

这会有一个问题，每次有小功能升级的时候，代码是最容易同步合并的，所以才会有“持续集成”这个概念，如果是一直伴随升级，总要比隔一个大阶段才升级好，升级成本应尽量分摊到平时，就像农妇养小猪，小猪每天长一点，每天都抱来抱去，不觉得吃力，即使长大了也还能抱得动。

现在问题就很明确了，一定要有一种方式来把这个依赖关系管理起来，很显然，已有的版本库是肯定管不了这些的，所以只能在外围做一些处理。

我们建立一个管理平台，除了管理实体文件的版本，还管它们之间的关系。具体这个关系如何收集整理，有两种方式：手动配置，代码分析。

手动配置是比较土的方式，开发人员每提交一个文件，就去这系统上手动配置它的依赖关系。代码分析的话，要在每次提交文件的时候解析文件的包含规则，找出确切的文件。这两者各有利弊，前者比较笨，但容易做，后者对代码格式的要求比较高，要考虑的情况较多。

我们的界面往往不是那么简单，HTML片段也可能有层次的，举例来说：

界面A里面包含了片段B，但是片段B自身又包含了片段C，所以这个依赖关系也是有层级的，需要在设计的时候一并考虑。

2. JavaScript模块

JavaScript代码的管理，比HTML片段的状况好一些，因为业界很多这方面的解决方案。但它们还是没有解决当依赖项产生变更的时候反向通知的问题。

所以我们还是得像HTML片段一样，把它们的依赖关系都管理到平台里。于是，每个JavaScript模块都显式配置了自己所依赖的其他模块，通过这种单向关系，形成了一套完整的视图。

在JavaScript模块的代码实现中，我们是不提倡直接写依赖关系的。很多通用规范，比如AMD，往往建议我们这样写模块：

但我们的系统是面向行业的，比这种通用解决方案要苛刻一些。比如说，如果有一天重构代码，JavaScript模块们调整了目录或者名字，这么写的就痛苦了，他必须把所有影响到的都去调整一遍，这是要搜索替换的。况且，就像上面HTML模板的部分提到的，影响了处于其他项目中依赖它的代码，缺少合适的方式去通知他们修改。

所以我们期望的是，在每个编写的JavaScript模块中只存放具体实现，而把依赖关系放在我们的平台上管理，这样，即使当前模块作了改名之类的重构处理，处于外部项目中依赖它的那些代码也不必修改，下一次版本发布的生成过程会自动把这些事情干掉。

对应到上面的这段代码，我们需要开发人员做的只是其中的实现，也就是moduleA的那个部分，外面这些依赖的壳子，是会在发布阶段根据已配置的依赖关系自动生成的。

如果需要，JavaScript模块还可以细分，比如类似Angular里面那样，把factory，controller和directive分离出来，这会对后续有些处理提供方便。

现在我们有必要讨论一下模块的粒度了，我们这里提到的都是基本的粒度，每个JavaScript模块中存放的应该只有一个很具体东西的实现。那么，有个问题，在我们发布的时候，是不是就按照这个粒度发布出去呢？

很显然不行，如果这么做，很可能会出现复杂界面一次要用10多个HTTP请求才能加载完它所需要的所有JavaScript代码的情况，所以需要做一些合并。

那么，合并的策略是什么？在我们这个平台上，开发人员又是要怎样定义这个合并关系的呢？我们需要在模块之上定义一个更大粒度的组织方式，这个方式与模块的关系，就好比Java里面，jar文件与class的关系。如果开发人员不显式配置，也可以通过全局策略，比如按最下层目录来合并。

这个时候，在实际使用这些代码的时候，需要带两个配置信息过去，一个是要动态载入的JavaScript文件（合并之后的），二是每个JavaScript文件中包含的原始模块。

3. 单元测试

如果JavaScript模块都已经被良好有序管理起来，就可以为它们考虑单元测试的事情了。单元测试对于提高基础单元的可靠度，是有非常重要意义的。

在我们这个平台里，可以把单元测试跟JavaScript模块关联起来，每个JavaScript模块可以挂一组单元测试代码，这些代码可以在线编写，在线运行。

单元测试的本质就是编写模拟代码来调用已有模块，考虑到我们的模块是JavaScript，所以很多思路都倾向于在浏览器端执行它们，对于单个模块的单元测试，这不是个问题。

如果要批量执行整个系统的单元测试，那就不一样了。把JavaScript代码先加载到浏览器中，然后再执行，很多时候并不需要这么复杂。我们完全可以在服务端把它们做了。

借助Node.js的能力，我们可以在服务端执行JavaScript代码，也就意味着能够把绝大多数JavaScript模块的单元测试在服务端就执行掉。当然，我们为此可能要多做不少事情，比如说，有些库需要移植一份node版的，常见的有AJAX调用等等。

注意了，能够在服务端做JavaScript单元测试是有先决条件的，代码的分层必须很良好，除了视图层，其他任何层面都不能操作DOM。所以我们这里主要测试的也正是除了视图层之外的所有JavaScript业务逻辑。至于视图层怎么办？这个真的很难解决，这世界上不是所有东西都能自动做的，只能先把可做的做了，以后再来考虑这些。

4. 文档和示例管理

4.1. 文档

现在我们有HTML片段和JavaScript模块了，需要给它们多一些描述信息。简单描述显然是不够的，我们还要详细文档。

这种详细文档可以通过某种方式生成，也可以由开发人员手动编写。与传统的离线文档不同，在线的文档更实时，并且，每当一个开发人员变更了他的文档之后，不需要经过全量构建，访问者可以实时访问到他的最新版本。

熟悉GitHub的朋友们可能早已习惯这种方式，在项目库里面存在一些以md格式结尾的文本文件，使用markdown语法来编写一些说明文档。

毫无疑问，这类格式很适合在线协作，所以我们也会在平台上集成这么一种编写文档的方式，无论是针对HTML模板还是JavaScript模块，或者是其他什么类型，甚至还可以用来当博客，就像月影同学的gitpress平台，能直接从GitHub上拉取文本或者HTML文件形成博客。

文档除了以集成的形式浏览之外，应当也可以以单独链接的方式发出去，这时候用户就可以像看一个新闻网页一样去浏览。如果再进一步做下去，还可以做电子书的生成，提供打包的离线文档。

4.2. 示例

在编写代码文档的过程中，可能免不了要插入示例，示例有两种形态，一种是纯文本，类似gist这样，一种是可在线运行，类似jsfiddle和jsbin这样。

这两种都有各自的优点，所以可以都做，示例的存放可以与文档类似，也应当能通过一个链接独立运行。

4.3. 幻灯片

有时候我们看到一些在线的幻灯片，觉得效果很帅，比如reveal.js，我们的开发人员有时候作代码分析或者走查的时候也不免要写一些演示，如果能把这些东西也随项目管理起来，能在线查看，会是很不错的一件事。所以我们也可以考虑给它们加个存储界面，甚至做个简易的在线编写器。

5. 项目与目录管理

说到现在，我们似乎还遗漏了一点什么。那就是以上提到的这些东西，以什么为组织单位来存储？

考虑到我们的这个平台是要管理一整个大产品的全部前端内容的，它里面应该分了很多项目，对应到子产品上，这么一来，很自然地，项目就成了第一级组织单位。项目之下，没有悬念地，只有目录了。

对于一个项目而言，它有哪些要做的事情呢？首先要能配置其实体存储位置。前面提到的这么多代码、文档之类，最终都是要实体存储的，怎么存？我们当然可以自己搞一套，在文件系统上做起来，但是还要考虑它们的版本管理，非常麻烦，所以不如直接对接某个版本库，调用它的接口去存取文件，这里配置的就是版本库的路径。

其次，要考虑从已有项目复制，类似GitHub里面的fork功能，不过内部处理机制可以略有不同，fork的项目默认未必要有实体文件，只有当产生了修改或者新增操作的时候才创建，剩下的还引用原来的就可以了。我们这里的项目复制功能是为项目化版本而考虑的，经常出现一个产品版本支持多个客户项目的情况，所以可能会用得着这个特性。

然后，也要考虑项目的依赖关系。依赖一个项目，意思是需要用到它里面的组件，所以实质是组件的依赖。提供项目依赖这个视图，只是为了未来变更的一些考虑。

6. 评论管理

之前提到，我们整个平台的目的是为了提高大型前端团队的协作能力，协作是离不开交流的。上述的任何功能，都应当带有交流沟通的能力。

比如说，如果开发人员A使用了其他人写的一个代码组件a，对其中一些细节有疑问，他应当可以对它进行评论。在他评论的时候，任何参与维护过这个组件的人员都能收到一个提醒，这时候他可以选择过来看看，回复这个疑问。同理，在文档、示例下也可以如此操作。

在互联网上有这类产品，用于在任意URL下挂接评论交流系统，比较有名的就是Disqus，我们可以看到很多网站下面挂着它，用于做交流评论，这样用户可以用一个账号在多个网站之间交流。国内也有同类的，比如多说，能够用微博、QQ等账号登录进行交流。

从我们这个平台本身看，如果是部署在企业内部作流程提升，引入外部评论系统的可能性就比较小了。因为在企业内部用，一定是希望这个员工的账号信息跟工号挂钩，也能够跟版本服务器账号等模块作集成，权限也便于控制。

从另外一个角度讲，某个人员登录这个系统的时候，他可能收到很多消息，来自不同的代码或文档位置，挨个点过去回复也有些麻烦，我们应当给他提供一个全局视图，让他能在一个统一的界面把这些问题都答复掉，如果他需要的话，也是可以点进去到实际的位置。

7. 用户和权限控制

从以上部分我们已经看到，这个系统是一个比较复杂的开发过程管控平台。这样的话，每个使用的人就应当可以登录，然后分配不同的权限等级。

未登录用户应当有一些东西的查看权限，但是不能发表评论。已登录的用户根据权限级别，可以控制能否创建、修改项目，创建、修改目录，代码，单元测试，文档等。

8. 国际化字符串管理

一个跨语言区域的Web应用不可避免要跟国际化打交道，这个事情通常是在服务端做，比如通过在界面代码中嵌入类似<% =getRes(key, lan) %>这样的代码，去获取相应的字符串，替换到界面里来。

这个事情是要占用应用服务器资源的，而且国际化本身其实是一个在运行之前就已经确定的事，完全可以把这个过程放在发布阶段就做掉。比如说，我们给每种语言预先就把代码生成多份，只是部署在一起，根据需要的情况来动态加载特定的那一份。

有不少客户端的国际化方案，是把资源文件拆细，以页面为单位存储，但这其实是不太合理的。第一个原因就是在Web2.0时代，“页面”这个概念本身就已经弱化了，到了单页应用里，整个应用都只是一个页面，这个时候，资源文件以什么粒度来组织呢？

我们提到过，采用MV*框架去做Web应用的架构，有一个目标是做组件化。组件化的意图就是某个组件可以尽可能随心所欲地放在需要的地方用。如果把资源文件的粒度弄小到对应HTML片段和JavaScript模块这一级，灵活性倒是有了，带来的问题就是管理成本增大。

做一个行业应用，最重要的就是业务一致性，这包括逻辑的一致性，也包括了术语的一致性。某一个词，可能在多个资源文件中都出现，这就增加了不一致的可能性。

所以，应当有一个统一的术语管理平台，一切界面上出现的文字或者提示，都必须来自这个平台。

9. 静态资源的管理

在发布系统的时候，除了需要发布代码，还需要发布图片等静态资源，这些东西也应当被管理起来。

静态资源在两种情况下可用：随产品发布，在本平台被引用。比如说有一个图片，在这个平台上作了管理，它可以被配置到某个项目上，在发布的时候导出。这个图片还可以被用链接的方式查看或者下载，如果本平台内部的一个文档或者示例要引用它，也是可以的。

10. 样式与主题管理

在Web系统里，样式和主题是很重要的一环。样式的管理和发布一直是一个比较复杂的话题，早几年一般都是分块写，然后组合合并，最近这些年有LESS，SASS和Stylus这类技术，解决了编写和发布的分离问题。

我们看看发布的最大问题是什么？是不同部分的合并。为了追求灵活性，不得不把东西拆得很细，之前HTML片段和JavaScript模块的处理方式都是这样。这么做，我们就需要另外一件事：这些细小的东西，尽可能要覆盖全面。

对应到CSS里面，我们要做的是把每种在系统中可能出现的元素、类别都作为单独的规则维护起来，生成一个全局的规则列表。不同项目间，实现可以不同，但规则的名字是固定的，定制只允许修改实现，不允许修改规则。如果要新增之前没有的规则，也必须在全局规则列表里先添加，再作实现。

样式规则被管理之后，可以在界面组件上对它作关联，也可以不做。做的好处是发布的时候能只把用到的那些样式规则生成发布出去，如果能接受每次发布全量CSS，那也无所谓。

除了规则，也需要考虑一些变量的管理，在CSS中合理使用变量，会大为减轻定制化所导致的工作量。

11. 一键发布

我们引入了这么一堆东西，其实是增加了发布的复杂度。为什么呢？

之前不管HTML、JavaScript还是CSS，都是手写出来，最多经过一个minify的工作，就发布了，整个过程很简单，两句脚本搞定。

现在可复杂了，先要分析依赖关系，然后提取文件，然后国际化字符串替换，然后合并，然后代码压缩，整个过程很折腾，不给配置管理员一个解释的话，他一定过来砍人。

我们有个原则：解决问题的过程中，如果引入了新的问题，要求负责解决原问题的人也一起解决掉。现在为了一些意图，增加了版本发布的复杂度，那也要有个办法再把这事摆平，至少不能比原来复杂。

所以我们就要把这些过程都集成到管控平台里，做一个一键发布的过程，把所有的这些操作都集成起来，配置管理员发布版本的时候只要点一下就可以把所有这些事情做掉。甚至说，这些流程还可以配置，能够加减环节。

这时候我们做到了跟之前发版本一样方便，能不能多做点什么呢？

可以把JavaScript单元测试集成到版本发布阶段。因为我们已经把JavaScript按照职责做了分层，并且把UI部分做了隔离，就可以在浏览器之外把这个单元测试做掉，平时提交代码的时候也可以做，最终在版本发布阶段再全量做一下，也是很有意义的。

代码依赖关系管理的另一个目的是什么呢？是最小化发布，既然我们都管理了文件之间的关系，那么，从根出发，显然是能够得出哪些代码文件在本项目中使用的，就可以每次从我们的全量代码库中取得确切需要的一部分来发布。这也是我们整个管控平台带来的优势。

12. 小结

我们这一篇比较复杂，提出了一整套解决大规模前端协作的管控机制。这套理论的本质是在开发和版本发布之间加了一个环节，把Web体系中除了服务之外的一切静态资源都纳入其中，强化了现有主流的一些基于命令行的前端工程化组织模式。

相比于传统行业，比如汽车制造，我们这个环节相当于生产流水线的设计，其中一些组件的存储就类似仓储机制，发布就类似出厂过程。

这个平台本身还有不少其他的可做的东西，比如甚至可以在上面做界面的可视化定制等，这些是长远的终极目标，在后面的文章里会谈谈一些考虑。