A little idea about ued front-end development

5.2 About ued front-end development ideas         5.2.1 currently ued front-end code is a page corresponding to a JS file, and more than a JS file code will be more than million lines, such code think how to maintain? If you avoid this awkward situation when working on front-end development, I think the best way is to divide and conquer,                if divide and conquer. First parse the general idea of the page, Initialize (init) event binding (events) page read value (getData) page write value (setData) reset page (resetdata) page Show (Setview) page check (checkdata) page asynchronous load                 (AJAX), page test (test) a page is basically so many processes to complete, the rest is business logic processing, for business logic processing, To pull away from this divide and conquer thought, to form a tree-like structure,                When you find that the branch needs refactoring, just change the branch and do the corresponding test case.         5.2.2 Although the above analysis seems to solve most of the problems, but there is a problem appears to be introduced, that is, JS loading efficiency problem, the tree structure is too deep, leading to JS inheritance chain too deep, then JS in the load when the efficiency will fall, How to ensure,                To minimize the depth of the inheritance chain in the case of a deeper tree structure? This may require the developer to be able to take some time to function with a guaranteed feature, which is to create a separate code package management for a functionally stable module, that is, to form a separate object.                 only need to be the corresponding place to introduce this object, so the inheritance chain will not be too deep, on the basis of the guarantee function, JS execution efficiency will be relatively improved.         5.2.3 Some method-level processing for front-end code development         &NBSp       init: function                       &NBS P           Initialize                 bindevent:object  &nbs P                         binding events               getdata: function                         nbsp   Read Data                  setdata: function       &NBSP ;                     Write data                 resetdata: function                       &N Reset data Bsp               setreadonly: function             &NBS P;       settings are read-only                 checkdata:function                       Validate data                 Ajax: Object                                 &N Bsp   Asynchronous data load                 Businesscomponent:object           Business components                 Bundle:object           &NBSP ;                     data transfer as an entry and exit for inter-module communication                 Test:function or object                   test case   &N Bsp     5.2.4 ideas about test-driven development                 (1) Interface Guide Development       &N Bsp             front and rear complete separation, in order to achieve independent development, the need for a predetermined interface format, once the interface format has been set, can be developed in accordance with the agreed-upon interface, but, each redevelopment, the need to simulate the corresponding test data                     This seems to be called test-driven development, for example, you need to submit form data, and the test data designed for the form submission action is a test case.                   (2) test data extraction             &NB Sp       Current test cases scattered in the function JS file, it appears that the code is rough, in order to pull out the test data, need to form a separate test file, just need to set up in the main file debugging development can, so the code more refreshing, if                     for remote data loading, it can be simulated in a native JSON file, and Ajax can be used to load the local JSON file.

A little idea about ued front-end development