新老代码融合，半年后你根本不知道哪些代码可以删，哪些代码可以留，很大时候这个问题会体现在具有公共特性的CSS中 如果你的CSS同时服务于多个团队，而各个团队的框架版本不一致，那么UI升级对你来说可能是一个噩梦！
如果你想做第三轮的UI升级，那还是算了吧......

事实上，我评价一个前端是否足够厉害，往往就会从这里考虑：

当一个项目足够复杂后，你私下做好了优化，但是你的优化代码不能无缝的让业务团队使用，而需要业务团队做很多改变，你如何解决这种问题

很多前端做一个优化，便是重新做了一个东西，刚开始肯定比线上的好，但半年后，那个代码质量还未必有以前的好呢，所以我们这里应该解决的是：

如何设计一个机制，让业务团队以最小的修改，而可以用上新的UI（样式、特性），而不会增加CSS（JS）体积 这个可能是组件化真正要解决的事情！

理想情况下，一个H5的资源组成情况是这样的：

① 公共核心CSS文件（200行左右）

② 框架核心文件（包含框架核心和第三方库）

③ UI组件（有很多独立的UI组件组成，每个UI组件又包含完整的HTML&CSS）

④ 公共业务模块（提供业务级别公共服务，比如登录、城市列表等业务相关功能）

⑤ 业务频道一个页面，也就是我们这里的list页的代码

因为框架核心一般来说是不经常改变的，就算改变也是对表现层透明的，UI采用增量与预加载机制，这样做会对后续样式升级，UI升级有莫大的好处，而业务组件化后本身要做什么滚动加载也是轻而易举

好的前端架构设计应该满足不停的UI升级需求，而不增加业务团队下载量

本文就如何分解复杂的前端页面提出了一些自己的想法，并且给予了实现，希望对各位有所帮助。

前端代码有分拆就有合并，因为最终一个完整的页面需要所有资源才能运行，但考虑到此文已经很长了，关于合并一块的工作留待下文分析吧

为了方便各位理解组件化开发的思想，我这里写了一个完整的demo帮助各位分析，由于精力有限，代码难免会有BUG，各位多多包涵：

https://github.com/yexiaochai/mvc

可能会浏览的代码：

https://github.com/yexiaochai/blade

最后，我的微博粉丝及其少，如果您觉得这篇博客对您哪怕有一丝丝的帮助，微博求粉博客求赞！！！