工程化工作流

开发
- 脚手架：创建前端应用的目录结构，并生成样板代码
- 公共库：维护着可复用的 UI 组件、工具模块等公共资源
- 包管理器：引入第三方库/组件，并跟踪管理这些依赖项
- 编辑器：提供语法高亮、智能提示、引用跳转等功能，提升开发体验
- 构建工具：提供语法校验、编译、打包、DevServer 等功能，简化工作流
- 调试套件：提供预览、DevTools、Mock、性能分析诊断等调试功能，加速修改-验证的主循环
测试
- 单元测试框架：提供针对组件、逻辑的测试支持
- 静态扫描工具：从代码质量、构建产物质量、最佳实践/开发规约等多个维度做静态检查
- 自动化测试工具：针对 UI 效果和业务流程，提供测试支持
- 性能测试工具：监测并统计出相对准确的性能数据
构建
- 打包脚本：在语法校验、编译、打包的基础上，进行合并、压缩、代码拆分、图片处理、SSR等极限优化
- 构建服务：支持多任务并行打包、通知
部署
- 发布平台：将前端资源上传至 CDN 或 SSR 渲染服务，或者以离线包的形式集成到移动客户端
- 迭代管理平台：提供 CI/CD 支持
监控
- 埋点平台：统计、分析业务数据，跟踪性能指标
- 监控平台：观察线上的异常信息，包括报错、白屏、流量异常等

前端架构细则

基础层

版本库

Gitlab 自搭建，或者 svn；每个版本一个分支，发布后锁死分支，并且每个分支独立线上地址并存方便回滚
纯前端版本发布

简单的gulp.task(gulp-sftp库)实现；或者Jenkins
统一脚手架

统一脚手架搭建，加快项目前期效率
node 中间层
- 代理：在开发环境下，我们可以利用代理来，解决最常见的跨域问题比如直接 node setHeader()；在线上环境下，我们可以利用代理，转发请求到多个服务端，减少客户端请求，比如一个 table 里拿员工信息列表，每个员工的姓名年龄是一个接口，头像又是另一个接口，这些可以放在 node 层去和 java 后端发出实际请求统一给到前端
- 缓存：缓存其实是更靠近前端的需求，用户的动作触发数据的更新，node 中间层可以直接处理一部分缓存需求。
- 限流：node 中间层，可以针对接口或者路由做响应的限流。
- 日志：相比其他服务端语言，node 中间层的日志记录，能更方便快捷的定位问题（是在浏览器端还是服务端）。
- 监控：擅长高并发的请求处理，做监控也是合适的选项。
- 鉴权：有一个中间层去鉴权，也是一种单一职责的实现。
- 路由：前端更需要掌握页面路由的权限和逻辑。
- 服务端渲染：node 中间层的解决方案更灵活，比如 SSR Nuxt 框架、模板直出、利用一些 JS 库做预渲染等等。
埋点监控数据

比如百度统计、腾讯移动统计接口；可以分析出用户点击量，各场景对比；并且遇到反常情况可以发出警报灯
安全

XSS 对用户输入需要转码（大部分时候要 server 端来处理）、

CSRF 攻击要求 server 端加入 CSRF 的处理方法

https 协议
eslint

硬性统一代码风格，团队协作
灰度发布

指在发布版本时，初始情况下，只允许小比例（比如 1~5%比例的用户使用），若出现问题时，可以快速回滚使用老版本，适用于主链路和访问量极大的页面。
前后端分离
- 中小项目常见的情况是后端只提供接口和让某个 url 指向某个 html，前端负责 html、css、js 等静态资源。
- 大型项目，建议前端负责除 html 以外的静态资源，而 html 交给后端处理。因为
  - 后端进行渲染，方便统一插入一些代码和资源，例如埋点 js，监控 js，国际化文本资源，页面标识符等
  - 当页面需要统一的头尾时（参考淘宝里我的淘宝页面），前端不应该关注这些跟当前页面无关的东西；
  - 如果通过 html 来管理，那么耦合度太高了，违背了解耦和分离的原则
Mock

解决在后端接口未好时，生成返回的数据。更好的 Mock 手法是直接嵌入到脚手架之中

应用层

单页和多页架构
- 页面和页面之间是独立的，不存在交互，因此当一个页面需要单独重构时，不会影响其他页面，对于有长期历史的项目来说，可维护性、可重构性要高很多
- 多页项目可以单次只更新一个页面的版本
- 多页项目的版本控制更简单，如果需要页面拆分，调整部分页面的使用流程，难度也会更低
- 利于灰度发布
- 多页项目的缺点是不同页面切换时，会有一个白屏时间
以应用为单位进行开发、发布

所谓应用即指一个业务涉及到的前后端代码。项目比较大的时候如果将所有页面的前端项目放在一起会很难维护，不方便权限管理，即使改一个页面整个项目页会更新所有资源
- 方便进行管理，当某个业务有需求变更时，可以只给研发人员该业务前端应用的 developer 权限；
- 在需要发布某业务时，只需要发布该业务的所属应用即可
基础组件库的建设

比如公司内多个产品系统共用 UI 风格组件库。

设计基础组件库的前提，是要求统一技术栈，比如使用 ts

要求：可扩展性强，文档清楚详细，版本隔离，和 UI 协调统一
技术栈要统一,方便招人，简化团队成员培养成本
- 三大框架选其一
- 需要兼容 IE8，建议 jQuery
- 组件库自建或者统一选择一个固定的第三方
- 一些特殊第三方库统一使用一个版本，例如需要使用地图时，固定使用高德或百度或腾讯地图
- 基础设施建设应避免重复造轮子，所有团队尽量共用，并有专门的前端平台负责统一这些东西，对于特殊需求，可以新建，但应当有说服力
浏览器兼容
- 配置 postcss，让某些 css 增加兼容性前缀
- 自写一个 wepback 的 loader，处理某些特殊场景
- 规范团队代码，使用更稳定的写法（例如移动端避免使用 fixed 进行布局）
CDN

把图片资源加到 CDN 服务器，降低服务器带宽成本
负载均衡
建一个内部技术平台