大型项目前端架构浅谈( 三 ) _前端架构

意义：
提高项目的稳定性，提高对业务的把控能力。降低bug数，降低资损的可能性，提前发现某些功能的bug（在工单到来之前）。
2.9、安全管理
前端的安全管理，通常要依赖于后端，至于只跟单纯有关系的例如dom.innerHTML= 'xxx '这种太基础，就不提了。
安全管理的很难从架构设计上完全避免，但还是有一定解决方案的，常见安全问题如下：

XSS注入：对用户输入的内容，需要转码（大部分时候要server端来处理，偶尔也需要前端处理），禁止使用eval函数；
https：这个显然是必须的，好处非常多；
CSRF：要求server端加入CSRF的处理方法（至少在关键页面加入）；

意义：
减少安全漏洞，避免用户受到损失，避免遭遇恶意攻击，增加系统的稳定性和安全性。
2.10、Eslint
Eslint的好处很多，强烈推荐使用：

降低低级bug（例如拼写问题）出现的概率；
增加代码的可维护性，可阅读性；
硬性统一代码风格，团队协作起来时更轻松；

总的来说，eslint推荐直接配置到脚手架之中，对我们提高代码的可维护性的帮助会很大。可以考虑在上传到gitlab时，硬性要求eslint校验，通过的才允许上传。
意义：
提高代码的可维护性，降低团队协作的成本。
2.11、灰度发布
灰度发布是大型项目在发布时的常见方法，指在发布版本时，初始情况下，只允许小比例（比如1~5%比例的用户使用），若出现问题时，可以快速回滚使用老版本，适用于主链路和访问量极大的页面。
好处有以下几点：

生产环境比开发环境复杂，灰度发布时可以在生产环境小范围尝试观察新版本是否可以正常运行，即使出问题，也可以控制损失。
对于大版本更新，可以先灰度一部分，观察埋点效果和用户反馈（即所谓的抢先试用版）。假如效果并不好，那么回滚到老版本也可以及时止损；
当我们需要验证某些想法或问题的时候，可以先灰度一部分，快速验证效果如何，然后查漏补缺或者针对性优化；

灰度发布通常分为多个阶段：【1】1%；【2】5~10%；【3】30~50%；【4】全量推送（100%）。灰度发布一定要允许配置某些IP/账号访问时，可以直接访问到灰度版本。
意义：
降低风险，提高发布灵活度。
2.12、前后端分离
这个并不是指常见的前后端分离，而是指在分配前后端管控的领域。
中小项目常见的情况是后端只提供接口和让某个url指向某个html，前端负责html、css、js等静态资源。
但大型项目并不建议这么做，建议前端负责除html以外的静态资源，而html交给后端处理，理由有很多：

后端进行渲染，方便统一插入一些代码和资源，例如埋点js，监控js，国际化文本资源，页面标识符等。这些通常是后端通过调用某些服务直接写入的；
当页面需要统一的头尾时（参考淘宝里我的淘宝页面），前端不应该关注这些跟当前页面无关的东西；
某些东西，如果通过html来管理，那么耦合度太高了，违背了解耦和分离的原则；
前端版本发布在后端引入某种功能模块后，可以从单独的页面控制前端发布内容，比更新html更方便，也利于灰度发布；

意义：
更规范的进行页面管理，降低页面和功能的耦合度，减少复杂页面的环境配置时间。
2.13、Mock
Mock也是常见前端系统之一，用于解决在后端接口未好时，生成返回的数据。
我个人不太建议开发一个专门的系统来Mock，更好的Mock手法是直接嵌入到脚手架之中。思路如下：

当在开发环境下，访问链接通常是localhost:8000/index.html，此时加入后缀 ?debug=true；
封装好的异步请求在发现当前链接有以上标志时，认为是测试环境，访问/userinfo 时，不去读取线上的数据（因为也读取不到），去本地环境读取 src/test_ajax/userinfo.json，并将内容返回给用户；
异步请求正常拿到数据，在页面中显示[原创水印-作者：零零水(王冬)，微信：qq20004604]；
当线上接口可以获取到数据后，从network里找到返回的数据，放入/ src/test_ajax/userinfo.json中，此时再次本地调试的话，相当于使用的是线上的真实数据。

</li>复制代码这种处理，可以降低mock的复杂度，随时更改mock时返回的数据，比单独开发一个mock系统性价比更高。
意义：
在前后端并行开发时，降低沟通交流成本，方便开发完毕后直接对接。