随着 SPA ，前后端分离的技术架构在业界越来越流行，前端需要管理的内容，承担的职责也越来越多。再加上移动互联网的火爆，各大公司也开始在前端投入更多的资源。

在传统的开发模式中，不仅会有 大量的资源冗余 ， 而且 因为项目中的交叉依赖太多，当出现技术方案变化时， IT 无法做到渐进式的、有节奏地替换掉老的代码，只能一次性替换掉所有老代码，极大地提升了技术方案升级的成本和风险。 并且 业务的要求， UX 的设计都需要等到开发人员写完代码，整个项目编译部署后才能看到实际的效果 。 反馈周期太长， 而 未来的任何一个小修改又需要重复这一整个流程 ， 以致于 无法发挥一个团队的全部效能，部分成员会出现等待空窗期，浪费团队效率。

这一切，使得业界对前端开发方案的思考上多了很多，以 快速开发 框架为代表推动的组件化开发方案 成为了 目前比较认可的方案 。

组件化开发的核心是 “业务的归业务，组件的归组件” ， 即组件是一个个独立存在的模块 。 使用 组件化开发 让 原有到系统级的粗粒度控制细化到了组件级别的细粒度控制，一个复杂系统的构建就是组件最终集成后的一个结果， 开发人员可以很容易了解该组件提供的能力 。 而 每个组件都自己独立的版本，可以独立编译、独立打包和部署， 不与全局或其他组件产生影响 。

把系统的构建架构在组件化思想上可以降低上手难度 和 整个系统的耦合度 ， 由于每个组件的职责单一，在系统中更容易被复用，所以对某个职责的修改只需要修改一处，就可获得系统的整体升级。独立的，小的组件代码的更易理解，维护起来也更容易。通过对组件的拆分粒度控制来合理分配团队成员任务，让团队中每个人都能发挥所长，维护对应的组件，最大化团队开发效率。

具体来说， 在前端项目中，构建各个 UI 界面占了 80% 以上的工作量 。 而通过 抽象 ， 我们会发现大量的组件可以在多个 UI 界面上复用 。 在组件化开发方案下，团队在交付开始阶段就从架构层面对应用的 UI 进行模块化， IT 部门 把需求分析阶段产生的原型中的每一个 UI 页面抽象为一个组件树， UI 页面自己本身上也是一个组件。这样的抽象显著降低了项目的工作量，在组件上对样式进行调整也会变得容易，对后续的修改和维护 的影响范围也能得到控制。

另一种 典型的场景 则 是某个功能界面，距离启动界面有多个层级，按照传统开发方式，需要按照页面一页一页的开发，当前一个页面开发未完成时，无法开始下一个页面的开发，导致团队工作的并发度不够。另外，在团队中，开发人员的能力各有所长，而页面依赖降低了整个项目在任务安排上的灵活性，无法按照团队成员的经验，强项来合理安排工作。这两项对团队协同度的影响最终会拉低团队的整体效率。

而 组件化开发强调业务任务和组件任务的分离和协同。组件任务具有很强的独立性和自治性，即在接口定义清楚的情况下，完全可以抛开上下文进行开发。这类任务对外无任何依赖，再加上组件的职责单一性，其功能也很容易被开发者理解。所以在安排任务上，组件任务可以非常灵活。

随着前后端分离架构成为主流，越来越多的业务逻辑被推向前端，再加上用户对于体验的更高要求，前端的复杂性在一步一步的拔高。对前端复杂性的管理就显得越来越重要。

组件化开发不仅 可以解决 当前的项目交付 效率难题 ，还指导了团队的运作，帮助了后期的演进，甚至在程序员最讨厌的写文档的方面也给出了一个巧妙的解法 ， 是企业开发软件降本增效的利器。