ExtJS官方的文件合并方案是，整个项目合并成一个方案。对于，具有多角色的系统是不合适的。
用户A拥有R1角色，登录系统后没有必要加载无关角色的代码文件。
- 根据Ext类的定义规则和关键字，分析每一个类文件的依赖关系
- 根据第一步得到的直接依赖关系，递归搜索所有的间接依赖关系
- 数据库表 User - Role - Menu 多对多关系。Menu结构<name,url>，其中name是菜单名称，url是Controller类名+方法名
- 页面上Menu即是，当用户登录之后，根据用户-角色-菜单关系，动态查询并渲染到页面
- 在系统发布前，采用预编译的方式，查询数据库Role - Menu，并搜索每一个菜单对应的Controller文件的关系，从而得到每一个角色需要的所有类文件。
- 把同一角色的文件合并到一个文件中。
- 用户实时行为 - 系统配置 - 页面元素 - 源码类文件，之间产生联系。
- 首先，启动数据库服务
- 运行模式。切换到当前目录，然后在命令行中运行命令node main.js test
- 调试模式。在命令行中运行node-inspector，然后在新的命令行中运行node --debug-brk=5858 main.js test
- 文件之间的依赖关系散落到各个文件内部，对于文件的替换、目录的变更是个麻烦事儿。 是否应该考虑全局的配置，类似spring Context文件或者H5的manifest文件？
- 目前只能解决类文件之间的静态关系（硬编码），对于动态关系还束手无策。
- 查询依赖关系采用esprima简单粗暴，效率低。
- 到目前为止实现了按角色合并成一个文件。应该按照子文件和主文件的依赖强弱来决策提前加载还是懒加载。
- 公共模块的查询现在是直接指定入口类，更合理的方式是根据依赖关系分析提取。
- 开发的时候，每个文件显示的声明依赖关系，并且用create + 别名的方式创建类。 在合并的时候，首先判断当前文件是否需要合并。是的话，去掉依赖声明，并且用new + 类名的方式创建类。
- 本项目采用的是按角色合并文件，是不是按模块（或者菜单）划分更合理？
- 既然已经缩小到具体用户了，是否可以结合用户的历史行为统计信息，来制定合并方案？
- db文件夹，数据库连接相关，包含了数据库文件
- lib文件夹，工具类库
- models文件夹，数据库操作类
- node_modules文件夹，插件
- test，目标测试项目源文件
- main.js入口主函数；findDirectDependence.js查询依赖关系；parse.js分析类文件结构，提取依赖关系； searchMenuByRole.js查询数据库，得到每个角色的所有菜单（结果放到Admin.txt、VODC.txt、VTC.txt）。
- dependence.txt直接依赖关系；deepDependence.txt包含间接依赖关系。
- AdminMini.js、VODCMini.js、VTCMini.js、commonMini.js分别是三个角色的文件和公共文件。
- 基于Node
- 用esprima构造每个类文件的语法树
- 用uglify-js压缩文件
- 调试采用node-inspector插件
- 数据库mongodb