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

2.14、定期备份
备份是常被忽略的一件事情，但当我们遇见毁灭性场景时，缺少备份带来的损失是非常大的，常见场景：

服务器损坏，导致存在该服务器上的内容全部完蛋；
触发某致命bug或者错误操作（例如rm -f），导致文件和数据全部消失；
数据库出现错误操作或出现问题，导致用户数据、公司资产遭受严重损失；

总的来说，没人想遇见这样的场景，但我们必须考虑这种极端情况的发生，因此需要从架构层面解决这个问题。常见方法是定期备份、多机备份、容灾系统建设等。
意义：
避免在遭遇极端场景时，给公司带来不可估量的损失。
3、应用层设计
3.1、多页和单页
除了特殊场景，通常推荐使用多页架构。理由如下：

多页项目，页面和页面之间是独立的，不存在交互，因此当一个页面需要单独重构时，不会影响其他页面，对于有长期历史的项目来说，可维护性、可重构性要高很多；
多页项目的缺点是不同页面切换时，会有一个白屏时间，但通常来说，这个时间并不长，大部分现有大公司的线上网页，都是这样的，因此认为是可以接受的；
多页项目可以单次只更新一个页面的版本，而单页项目如果其中一个功能模块要更新（特别是公共组件更新），很容易让所有页面都需要更新版本；
多页项目的版本控制更简单，如果需要页面拆分，调整部分页面的使用流程，难度也会更低；
灰度发布更友好；

之前面试的一家，采用了单页的形式，之前因为种种原因，同时采用了ng和react 。由于项目历史也比较久（3年以上），结果导致目前继续维护更新的难度很大，即使想部分重构，也很麻烦。
意义：
降低长期项目迭代维护的难度，
3.2、以应用为单位划分前端项目
在项目比较大的时候，将所有页面的前端文件放入到同一个代码仓库里，我之前参与过一家企业的前端项目开发，发现其就是这么做的。根据使用经验来看[原创水印-作者：零零水(王冬)，微信：qq20004604]，存在很多问题：

会极大的增加代码的维护难度；
项目会变得很丑陋；
不方便权限管理，容易造成页面误更改或代码泄密；
任何人都有权利改任何他能看到的页面（在合并代码的时候，管理人员并不能确定他本次修改的页面是否是需求里他应该改的页面）；
发布成本高，即使改一个页面，也需要发布所有资源；

因此，我们应该避免这种现象的发生，个人推荐以应用为单位进行开发、发布。所谓应用即指一个业务涉及到的前后端代码，好处很多：

方便进行管理，当某个业务有需求变更时，可以只给研发人员该业务前端应用的developer权限；
在需要发布某业务时，只需要发布该业务的所属应用即可；

意义：
规范项目，增加代码的安全性，降低项目维护成本。
3.3、基础组件库的建设
这个蛮基础的，对于组件库的建设，不建议研发人员较少时去做这件事情，专职前端开发人数少于10人时，建议使用比较靠谱的第三方UI库，例如Antd，这样性价比更高。
设计基础组件库的前提，是要求统一技术栈，这样才能最大化基础组件库的效益。组件库建议以使用以下参考标准：

使用ts；
可扩展性强；
适用程度高；
文档清楚详细；
版本隔离，小版本优化加功能，大改需要大版本更新；
和UI协调统一，要求UI交互参与进来；

总的来说，建设起来后，利大于弊，但是需要专人维护，因此还是有一定成本的。
意义：
统一不同/相同产品线之间的风格，给用户更好的体验，减少单次开发中写UI组件时浪费的时间和人力，提高开发效率。
3.4、技术栈统一
前端有三大主流框架，还有兼容性最强jQuery，以及各种第三方库，UI框架。因此项目需求如果复杂一些，很容易形成一个大杂烩。因此前端的技术栈必须统一，具体来说，建议实现以下举措：