前端架构解析

1、前端架构的问题

2、前端架构问题的切入方向

3、解决方案与现实的交汇

4、前端特点对解决方案的影响

1、前端架构的问题

无论web前端的架构如何的变化和改进，甚至是用框架或者是基于各方面的改进调整，最基本的请求返回上所有的步骤是不可缺少的。这是web前端架构的根基。最基本的请求返回路径如下：进入对应的前端页面->触发页面事件->收集数据和校验数据->组装数据->发送请求至渠道服务器->服务器返回数据->解析数据结果->组装数据结果->显示数据结果或触发新的页面事件。

根据大事必做于细的原则，要将基本请求返回路径中每个环节做详细思考并出一个可调整的清单：

a)在刚进入前端页面时，BOM、DOM、JS的组织管理问题和预加载问题

b)事件管理，包括事件与对应处理函数的绑定管理，动态和静态的问题

c)事件处理函数获取数据的方式和数据校验问题

d)如果事件函数需要同服务器做交互，请求数据的组装是否要设定统一的标准

e)跟服务器做交互的时候，请求的方式、头部认证、返回数据格式、超时设置的问题

f)服务器返回数据对正常返回和异常返回的处理标准，有没有必要对异常返回做统一的处理问题

g)解析正确返回后，对复杂的数据结果解析问题，如数据格式转换、文件处理等

h)数据结果解析完成后，将数据结果展示给用户，页面的渲染、展现方式是否要做统一标准

2、前端架构问题的切入方向

这些问题是基于纵向的请求返回对前端提出的要求。解决这些问题，要从前端的横向切面去观察判断，必要的时候要参考系统的非功能需求和业务增长预期。

问题a的入手方向是从系统的客户端去解决，通常的客户端有PC页面、APP、微信小程序等，每种客户端对预加载的要求不同，PC客户端中的瘦客户端是随用随加、PC客户端中的胖客户端可以做一次性大数据量加载、APP可以随同客户端安装时一次性加载、微信小程序也可以做一次性加载。BOM+DOM+JS的组织管理是看整个系统的规模与多大，通常企业集成的系统是要做统一管理，最起码做到DOM可以就近找到对用的JS文件或者是JS文件需要有统一的文件管理标准。目前前端的主流框架基本偏向于JS文件统一管理配置，而遗留系统的基本偏向于可就近找到对应的JS文件。

问题b的入手方向是用户与系统的交互性，如果整个业务需求倾向于客户能够更多的动态交互，那么事件管理中需要将动态绑定做详细的规范，反之只需要对少量动态绑定做足够的中断测试考察动态绑定是否打乱正常的动态绑定效果。事件的绑定管理是否要做统一的标准，要看页面的复杂程度，如果页面非常复杂，必须将事件绑定统一到每个页面指定位置以便于区分。目前前端主流框架是偏向于事件绑定的统一管理，将所有的事件绑定罗列到指定位置。

问题c的入手方向要分问题看，数据的获取方式要从客户端运行效率、开发人员的便利性去考察；数据校验问题要以业务需求中数据为基准，设立统一的数据校验规则，数据的通用性校验在前端处理，数据的业务规则校验必须要与服务器做交互进行校验。这两个问题在目前的前端框架中都有体现，数据获取方式是各个框架有各个框架的规则，数据校验规则基本是根据业务要求去做配置性处理。遗留系统的情况于此一致，不过在数据校验规则方面可能不是配置性处理，而是手动编写校验函数，并且校验函数也分布的比较零散。

问题d的入手方向是看请求数据的复杂程度，如果数据量非常少，5个以内，没有必要做；如果请求数据的复杂程度中等但请求数量很大或者请求数据的复杂程度很高，那么对请求数据做统一组装处理是非常有必要的。

问题e的入手方向是跟数据请求设置、客户身份验证、数据返回设置、超时设置。这些设置信息在是标准的企业环境下是应该做统一设置的，不过很多遗留系统有可能是每个请求自己设置自己的。统一设置信息的原因是它与系统的安全性有着强关联，是践行系统安全的一个重要方面。

问题f的入手方面是业务需求，即便是业务需求没有提，也要统一做设置。一般来说，正常返回和异常返回的处理是一个系统正规和不正规的分界线，也是菜鸟和专业的分界线。

问题g的入手方向是基于业务需求来处理，一般来说这部分是手动编码来处理。

问题h的入手方向是数据结果的展示，涉及到模板、数据、显示方式等。

3、解决方案与现实的交汇

我们对着这些问题和解决思路，基本上可以罗列出一个前端的解决方案。接下来要做的是根据这个解决方案做技术选型或者根据这个解决方案对照现有的遗留系统技术方案。到这个时候，程序员的技术才可以发挥效力。

目前主流前端框架都还向着少编码的方向上去努力。JS编程语言的规范则是不断削弱浏览器兼容的壁垒，同时提高易用性，也在向着少编码的方向上努力。这两个的方向上一致的，表示这前端的主流方向是少编码，分歧点是框架来处理解决方案中的某些重点部分或者用es6可能完全胜任，框架是一种习惯，es6标准的改进是普降甘霖。

很早以前就习惯使用Jquery，但是这个框架对着解决方案来的话，在预加载上比以前有进步；BOM+DOM+JS的统一管理上有点弱；事件的统一管理也比较无力，用到哪里写在哪里；数据获取方式非常容易，数据校验可以使用配置性处理；请求数据组装需要完全的手动处理；与服务器的交互上可以做统一设置；数据返回处理中异常处理也可以做统一设置；数据的格式转换需要完全手动处理；数据结果展示部分则需要手动处理，即便引入UI也要如此。

每个框架并不是完全能承担解决方案的落地，如此便需要接触更多的技术组合来对比每种选择的大致编码量、维护性问题。大致编码量决定了开发的实际支出，维护性问题决定了系统的日常开支。