此次通过一个新增模块的业务，尝试了用全新的方式去实现。个中波折感悟，以下一 一表述。
总的来说，新框架的核心思路还是模块化，架构上通过目录结构的形式，利用RequireJs，业务逻辑和通用模块的设计上去做到模块的独立性，降低模块间的耦合。模块化一直也是我们最近前端架构调整的一个方向，新旧对比而言，在模块化的思路上我感觉主要有以下几个区别：
旧：
1，模块划分上，主要以大的功能区块来划分，模块的体量比较大，通常会包含几个页面；
2，模块内没有或较少再去细分模块，导致模块内部的公用css、img、js方法等复用度参差不齐；
3，优点是目录相对精简，大模块内部的结构符合习惯的目录放置方式，理解上没有门槛，可以快速在团队中形成规范；
新：
1，模块划分上，视觉上通过页面小模块为单位来划分；业务逻辑上，结合视觉模块，通过base模块/全局业务模块/部分通用模块/单模块来划分；
2，划分上层级明晰，在大模块的划分内部有小模块的划分，通过requireJs来解决依赖加载和明确模块间的关系；
3，模块划分单位较小，导致模块会较多，此时处理目录结构可以改进；模块内部html，css，js的引入应该更具模块化的思路，让模块内部各文件联系更紧密。
下面主要就新框架的思路以及具体做法来展开说明一下。
一，模块划分及目录结构
我们以自助报修和24小时托管的蒙层来说明模块划分的思路。
显而易见的，两个页面的蒙层的共同特征决定了他们应该是一个模块，不管是页面样式，还是底部按钮的js，还是数字动画，都是一样的。所以，蒙层应该是独立出一个模块，然后两个页面的蒙层来继承这个蒙层模块的样式与js方法；目录结构如下：
在文件放置位置上，通过页面名称来放置同一页面的不同模块。如报修页Maintenance下，有三个不同模块，蒙层模块，报修弹窗模块，报修原因弹窗模块，表明了这三个模块的作用页面；如此具体模块的页面结构关系便清晰了；
在文件命名规则上，通过命名来表明模块的继承关系，如Hour24文件夹下的 H24Matte，通过后半部分单词来表明其继承的模块的名字；如此，模块的功能上的从属关系也会很明确；
二，模块继承的具体实现
我们还是以蒙层为例，分别来说css和js的复用与继承；
1，CSS
当前H24Matte和报修蒙层RepairMatte的公用样式文件就是Matte模块下的main.css，引入方式依旧是如以往的方式----放置于global.css中，全局引用；我认为当前的方式有两方面的弊端：其一，只是两个蒙层的公用样式，放置于全局的css中一并压缩，很多不需要用到这些css的页面也引入了这些代码，增加了css的代码量，影响性能，也增加了样式覆盖、相互影响的风险（当然我们有做防覆盖的措施，可以杜绝）；其二，公用放全局，没有实现模块的高移植、快速复用的特性；如果不放在global中全局引用，而是通过页面<link>标签的方式引入，这样也无疑增加了模块复用的麻烦；因为你必须要记得给你继承模块的每个页面去添加一行link引入。
我认为，要实现模块css的快速移植复用，不应该去过多考虑我继承的模块的公共css在哪儿引入；而应该通过继承的js方法动态的将公共的css插入到所继承的页面模块中；如此，只需要在模块的公共js写一个公共的插入css的方法即可；
2，JS
H24Matte和报修蒙层RepairMatte的公用js文件就是Matte模块下的main.js，引入方式不同以往。如下所示：
通过这种依赖关系，就实现了js内部方法的继承，requireJs会根据依赖模块自动去请求js文件，所以我们不需要将Matte/main.js通过<script>标签来引入。那么当前页的js又是如何跟当前蒙层的html页面关联起来的呢？看下图：
三，新框架的其他使用体会
1，dom操作
在日常开发中，我们经常会碰到这样的问题：我们给一个div加了某个class，并在js中对class绑定了事件操作；忽然有一天你发现这个div上的事件操作没有了，不执行了；最后你debug才发现原来其他同学不小心改了这个class名字，导致绑定失效了。
这种事情绝对是多发的，会降低我们的开发效率；当然我们也可以在团队内部约定一些规范来减少此类事情的发生，比如要对某个class去做增删改样式操作时，只增加class，不改不删；但是如此一来同样有弊端，就是项目一大，时间一长，会产生很多冗余的class和css代码，降低性能。在我们的新框架中是如何去解决这一痛点的呢？看下图：
2，事件绑定
除了在js中获取dom来操作，绑定事件；我们也可以直接在html元素上通过属性去绑定事件操作。例如<a href="#" onclick="doSomething()"></a>,在新框架中主要是通过下面的方法来绑定事件操作：
事件绑定的js写法
此种事件绑定方法和传统绑定方法出入不大，只是用另一种方式实现罢了；但是这种方式的绑定也是有必要的；因为新框架的js都是通过面向对象的方式来写的，通过类的封装方式；如此情况下再用传统的方式绑定，就需要在js中写function方法。如此的话，代码整体性和易读性上都会有缺损，也不利于继承；
3，三种函数格式
这是新框架中约定的三种函数格式的写法规范，分别对应不同的功能或范围；当然这只是命名规则上的规范，并没有对于方法的暴露与私有做限定操作。当然规范依然是有意义也是有必要的，这样的代码规范有利于代码的阅读和查找操作；有利于代码块的整理，比如所有的事件绑定操作的函数都置于底部事件操作区块，利于查找；私有方法放一块，置于事件绑定之上；会向外提供操作的方法则放于顶部；
4，模块的独立性
新框架中的模块划分，模块间的独立性是给我印象比较深刻的一点；接下来我将以报修页面的点击自助报修按钮这个事件来说明这一特性。
我们先来看看点击自助报修按钮做了一些什么事情（假设用户已登录）：
1，点击按钮，发送ajax请求用户屏幕详情；
2，判断请求到的数据，提取出可保修的屏幕及其信息；
3，插入相关数据到可报修屏幕列表框，并弹出窗体；
4，检测弹窗是否弹出，弹出则隐藏蒙层上的元素，保持视觉上的干净；
这里涉及到两个模块，一个是报修页蒙层模块；另一个是可报修屏幕的列表弹窗模块；如此，我们可以再来分析上述事件分别属于哪个模块。
事件一，发生在按钮操作上，显然属于 ---->蒙层模块;
事件二，发生在按钮点击后对数据的操作，也属于---->蒙层模块;
事件三，数据来源于蒙层模块的ajax请求并操作后的数据，属于---->蒙层模块；
把数据插入弹窗内容区，属于---->弹窗模块；
弹出弹窗---->属于全局的modal模块的方法；
事件四，弹窗弹出，属于---->属于全局的modal模块的方法；弹窗模块；隐藏蒙层的某些元素，属于---->蒙层模块；
由此，我们可以看出，一二都是模块单独的内部事件，不涉及不同模块之间的交涉，暂不表；我们主要看看事件三、四这种交叉的逻辑怎么去实现，以保证模块间的界限和独立性。以事件三为例：
1，因为数据来源于蒙层模块的操作结果，所以应该是在蒙层模块中操作；
2，而获取数据后怎么去使用数据插入模板，写入弹窗内容区，都不属于蒙层模块，所以这一块操作应该放在报修模块内部去操作；
3，于是报修模块内部实现了数据接收后的插入模板的操作；
4，但弹窗事件属于全局事件，所以报修弹窗模块也只是插入模板内容，模板写入后并不负责弹出事件；
5，弹窗后的回掉事件根据不同模块，操作也不同，所以全局弹窗只提供弹窗打开/关闭的毁掉事件，具体操作由调用的模块去完成；
这种模块js操作的方式，很好的保持了模块的独立性。内部方法内部实现，有交叉操作的地方通过get/set方式来提供操作的入口和出口，分工明确，互不牵扯；如此，模块的移植也就非常的便利了，复用的简便性大大提高。
四，总结
此次通过新框架来开发新的业务模块，个中虽有困难，但也算顺利完成了预期目标。所以，新框架有一定的学习成本，但是并不高，相对于中间获得的感悟，还是非常值得尝试。
我们原有的方式，是大家一直习惯的开发方式，包括思维方式和代码书写方式。在开发速度、相互交流、代码阅读上是有优势的；而且对于定位快速开发迭代的公司业务，短期内的优势也是比较明显的。缺陷在于，项目逐渐前行增大之后，由于模块间的粘连较多，代码混杂度较高，可维护性较差；模块间相互交叉多，导致补丁式代码增多，包括css等冗余代码也会一直增加，降低性能；易读性差。
新框架的构建方式以及代码规范，在构建前期会有大量底层工作要做；但是基本框架完善后，这种优越性是显而易见的；目录和命名清晰，模块间耦合降低，复用方便，后期开发速率的提升等等。当然，新框架是有一定的学习成本，包括使用规范，命名规则，引入规范，模块划分，业务模块分割思路，以及面向对象的理解，还有requireJs的使用以及框架的base方法的熟悉等等。但是改革总是如此，没有牺牲和付出的改革是不值得去做的。阵痛过后，就是春天。
