工作中的前端工程化问题
看过张云龙在git上关于前端集成的讨论，总结下工作中的问题。去年初的时候读过，之后也思考总结过我们平时开发项目中遇到的问题。现在再重新梳理一遍，主要是组件化。InfoQ 上的文章 && github 上文章
先谈谈在工作中遇到的问题。平时工作中负责的管理系统较早的开始在两三年之前，采用了某个 SPA 框架，以及搭配的 UI。有几个现基于此技术系统需要不时升级维护。在开发过程中，经常遇到该 UI 引起的很诡异的 bug，并且该 UI 源码较难读懂维护。于是在新的系统中使用了另一套 UI，新的 UI 代码容易理解，也容易在此之上扩展。
遇到的问题
最开始接触这些项目时，规规矩矩按照框架的配置规范开发页面，遇到问题看着代码排查，觉得还很顺手。时间久了，做的多了，感觉有不少重复的工作，比如每次添加页面做的事情有些过程是完全重复的。在一个项目中有一个复杂的页面，代码有 1000 多行。维护这个复杂的页面实在麻烦，于是开始思考解决这种问题。
在那个复杂的页面中，确实有很多事情要做，主要有几个大块头：一个按钮点击之后弹出对话框，选择几个数据，这样的组件有5个左右。然后显示在页面上；还有个是选择后的资源列表有优先级要求，要求支持排序；还有最下面的非常独特的功能强大的可编辑表格。
组件封装
对这个问题，解决的方法是在原来的基础UI上，封装业务UI。将上面提到的大块头封装为一个业务级的UI组件，每个UI组件只对外暴露 setValue（编辑页面时，填充内容）， getValue（提交表单时，获取组件数据），render （渲染组件）。封装完业务UI之后，工作轻松了不少，不过还有些重复的劳动力，就是刚提到的每个页面很相似，只有少许的不同，每次新增模块，复制一份修改，也显得太不专业了。不过项目快结束了，不管了。
多个项目中的组件模块化
重构完那个项目之后，接手了几个项目的维护工作。发现了更多的问题，总结一下大的问题：
- 几个项目的组织不尽相同，虽然项目大体是一致的，但在配置信息、用户信息、导航处风格不一样（插一句：导致如此的原因与选用的框架有关）。
- 有些项目还处于之前提到的状态，类似功能在几个项目中多种实现。
- 上面提到的新增一个模块，复制修改，在几个地方配置。
- 维护公共模块。几个项目中公用框架和基础UI，都是独立的。
- 采用的框架是独立的，遇到问题只能看代码，前人踩过的坑后人接着踩。
受上面文章影响，平时也用 grunt 工具，考虑用 yeoman 解决这些问题。对第一三问题，除了规范，就是使用 yo 定义 generation 生成项目脚手架，新增模块和组件都能用命令生成一个空的文件。对第四个问题最好的解决办法是，在一个独立的项目上维护这些公用库，搭建自己的私有 bower，维护自己的 cdn。对公用库，要求严格些，必须通过测试，有齐全的文档和 demo。第五个问题，可以在 gitlab 上记录 issue。
后来
跟大家讨论过上面的问题之后，大家普遍觉得那个框架太旧了，不如投奔开源的，先看看 angularJS 吧。
文章之外
业务UI 为什么有差异？项目时间长，前后负责项目的产品和码工都不是同一个人，更不用说几个不同的项目了。如果前端UI库齐全，可以反过来要求产品设计遵循规范的UI。
