阶段一：架构设计及创建脚手架开发

设计闭环：

项目之间的关系，架构设计图：

模块关系图：

作品的数据结构设计

{
  // 作品
  "work": {
    "title": "作品标题",
    "setting": {}, // 配置项
    "props": {}, // 页面 body 的样式
    "components": [
      // components 是一个有序的数组
      // vnode格式
      {
        "id": 1,
        "name": "",
        "attrs": {}, // 样式属性
        "children": [] // 文本内容
      },
      {
        "id": 2,
        "name": "",
        "attrs": {}, // 样式属性
        "children": [] // 文本内容
      }
    ]
  },

  // 画布中当前选中的组件
  "activeComponentId": 1
}

web 前端架构师阶段一

导论

关键词

• 流程图 - 分析需求的工具
• 全局思维、整体思维、闭环思维 - 架构师思维来分析需求
• 业务组件库 - 独立拆分出来，复用
• 自定义事件统计 - 业务的重要性，如何实现

学习方法

• 要有耐心，不要一心想着写代码，需求和设计很重要
• 要坚信：技术永远都是为业务服务的，技术是实现业务增长的工具

注意事项

• 不要关注细节，要看整体，看范围
• 设计是判断可行性，不确定的就调研以下
• 设计要考虑复杂度，越简单越好，不要过度设计，不要为了设计而设计

研发流程

• 1.项目启动

  • 1.1 项目启动会
  • 1.2 项目计划，项目角色划分

• 2.需求

  • 2.1 编写需求
  • 2.2 评审需求
  • 2.3 UI 视觉稿评审

• 3.技术方案设计

  • 3.1 技术难点调研
  • 3.2 技术方案设计
  • 3.3 技术方案评审

• 4.开发

  • 4.1 写代码，包括单元测试
  • 4.2 代码走查
  • 4.3 合并代码
  • 4.4 自测

• 5.联调

  • 5.1 前后端联调
  • 5.2 UI 视觉稿确认
  • 5.3 产品需求确认

• 6.测试

  • 6.1 提测
  • 6.2 测试
  • 6.3 修改 bug
  • 6.4 测试准出

• 7.上线

  • 7.1 预览环境上线
  • 7.2 预览环境回归测试
  • 7.3 线上环境上线
  • 7.4 线上环境回归测试

• 8.项目总结

  • 总结分析项目的进度、质量、风险、问题等，争取下次项目规避

第 1 周：需求分析和架构设计

需求分析

脱离业务的架构就是耍流氓。 架构师必须要深入理解需求、参与需求、看透需求背后的业务本质。

• 熟悉产品需求

  • 以架构师的思维分析需求，不能只停留在表面实现需求，要考虑怎么实现能给业务带来增长

    • 全局思维、整体思维、闭环思维，不能只考虑自己，要全局考虑整个团队，要做到有输出、有输入、有结果

• 一个面试题，h5 抽奖需求的理解

  • 绘制出整个流程图

• 项目的浅层需求

  • 需求指导设计，设计指导开发
  • 分析表面需要实现的功能，如登录、创建作品、编辑、发布、访问作品等

• 项目的深度需求

  - 通过浅层需求分析，进一步分析需求
  
  	- 需求闭环
  
  		- 数据统计
  
  			- 分渠道统计
  
  - 作品的管理
  

  作品统计 作品发布 h5 后台管理

  	- 作品发布url不能变
  
  		- 支持多渠道
  
  	- H5端需要分享
  
  		- 要对业务增长负责
  
  	- 后台管理
  
  		- 数据统计
  		- 作品管理
  
  			- 能快速下线作品，防止有违规内容
  
  		- 用户管理
  
  			- 能快速冻结用户，防止有违规用户
  
  		- 模板管理
  
  			- 控制模板展示与隐藏
  

技术整体架构设计

• 分析需要哪些项目，各项目之间的关系

  • B 端（中台）

    • biz-editor-fe
    • biz-editor-server

  • C 端（前台）

    • H5

      • SSR-server

  • 管理后台（后台）

    • admin-fe
    • admin-server

  • 独立的业务组件库

    • 组件平台

  • 自定义事件统计服务

    • 需求

      • 自定义事件埋点

        • 可区分参数与渠道

      • 分析统计

      • OpenAPI

        • 让 B 端可查看具体制作出的 H5 所有统计数据
        • 管理后台也可以查看所有数据

    • 自研

      • 日志收集
      • 日志分析
      • OpenAPI

  • 脚手架

    • 创建
    • 发布

• 作品的数据结构设计

  • 几个问题

    • 1. 在点击”保持“按钮的时候，往服务端传递的数据结构是什么样子？
      • 答：使用 vnode 结构，与 vue 的虚拟 dom 数据结构保持一致
    • 2. 如果保证画布和属性面板是同步更新的？
      • 答：将数据存到 vuex 中，表示当前选中的组件
    • 3. 如果再扩展一个”图层“面板，数据结构该怎么设计？
      • 答：使用单一数据源，数组结构，所有的图层都是 computed 计算出来的索引，而不是一个单独的数据

  • 基本思路

    • 每个组件尽量符合 vnode 规范
    • 用有序的数组来组织数据
    • 尽量使用数组引用关系，数据不要冗余

  • 数据流转

    • 核心：B 端、C 端、管理后台，共用一个数据库

      • 创建作品：初始化一个 JSON 数据
      • 保存作品：修改一个 JSON 数据
      • 发布作品：修改一个标记状态
      • C 端浏览作品：获取 JSON 数据，SSR 渲染页面
      • 屏蔽作品：修改一个标记状态，C 端来判断是否渲染

    • 从数据的角度去看整个流程

• 注意

  • 这一步千万不要抠细节，不要拿代码实例去对比

    • 做技术方案设计为的是寻找一个方向，论证：可行性、扩展性、复杂度高低

      • 保证设计的方向和思路是一样就行

• 写《整体技术方案设计》文档

  • 学会如何写技术方案设计

    • 随性一些，解释一下你要如何做即可

      • 文字描述，画图，流程

    • 如果你写不出来，说明你没理解需求，正好暴露问题

  • 文档目录

    • 1. 需求
    • 2. 模块设计

      • 模块的拆分和关系图

      • 模块的关键功能

      • 特殊模块重点说明

        • 组件库，同时用于编辑器和 H5
        • 自研统计服务
    • 3. 作品的数据结构
      • 数据流转关系图
    • 4. 扩展性保证
      • 扩展组件库
      • 扩展编辑器的功能
    • 5. 开发提效
      • 脚手架
      • 组件平台
    • 6. 运维保障
      • 线上服务和运维服务
      • 安全
      • 监控和报警
      • 服务扩展性

第 2 周：脚手架架构设计和框架搭建

• Lerna

第 3 周：脚手架核心流程开发

• 准备阶段

第 4 周：脚手架命令注册和执行过程开发

• 命令注册
• node 多进程

第 5 周：脚手架创建项目流程设计和开发

关键

• 命令行交互
• egg.js
• mongodb

mongodb

命令行交互

第 6 周：脚手架项目和组件初始化开发

• ejs 模板渲染
• glob 文件筛选
• 项目标准安装和自定义安装
• 组件库初始化和安装