关于UED前端开发的一点想法

Posted 2020-07-18 zhaojunyang

5.2 关于UED前端开发的一点想法

        5.2.1 目前UED前端代码是一个页面对应一个JS文件，更有甚者一个JS文件的代码会超过万行，这样的代码试想该如何维护？如果在从事前端开发的时候避免这种尴尬的局面，我想最好的方式就是分而治之，

                如果分而治之？首先解析页面的一般思路，初始化（init） 事件绑定（event）页面读值（getData）页面写值（setData）重置页面（resetData）页面展示（setView）页面校验（checkData）页面异步加载

                （ajax），页面测试（test）一个页面基本上就是这么多过程进行完成地，剩下的就是业务逻辑上的处理，对于业务逻辑的处理，在通过这种分而治之的思想去抽离，行成一种树状结构风格，

                当发现那个分支需要重构时，就只对这个分支做变更，做好对应的测试用例。

        5.2.2 虽然上面的分析看似可以解决绝大多数问题，但是有一个问题似乎引入了，那就是js加载效率问题，树状结构太深，导致js继承链太深，那么js在加载的时候效率就会下降，如何保证在较深的树结构情况下，

                尽可能地减少继承链的深度呢？这可能需要开发人员在功能保证的情况下，再花上点时间了，就是对功能稳定的模块，形成独立的代码包管理，也就是形成一个独立的对象。

                只需要再对应的地方引入这个对象即可，这样继承链就不会太深，在保证功能的基础上，js的执行效率也会相对提高。

        5.2.3 关于前端代码开发的一些方法级别的处理

                init: function                                   初始化

                bindEvent: object                           绑定事件

                getData: function                           读取数据 

                setData: function                            写入数据

                resetData: function                         重置数据

                setReadonly: function                    设置是否只读

                checkData: function                       校验数据

                ajax: object                                     异步数据加载

                businessComponent: object          业务组件

                bundle: object                                数据传递，作为模块间通信的入口与出口

                test: function or object                   测试用例

        5.2.4 关于测试驱动开发的一点想法

                (1) 接口指导开发

                    前后台完全分离，为了做到独立开发，需要预定接口格式，接口格式一旦定了，既可以按照约定好的接口进行开发，但是，各自再开发的时候，都需要模拟对应的测试数据

                    这似乎可以称为测试驱动开发，例如，你需要提交表单数据，针对表单提交动作设计的测试数据就是一个测试用例。

                 (2) 测试数据抽离

                    目前的测试用例散落在功能js文件中，显得代码粗糙不堪，为了把测试数据抽离，需要形成独立的测试文件，只需要在主体文件中设置调试开发即可，这样代码更加清爽，如果

                    遇到远程数据加载的情况，可以通过本地json文件的方式进行模拟，ajax完全可以实现加载本地json文件的效果