介绍我做过的项目 - P 项目

Wed, Apr 14, 21

从 2020 年 03 月,我加入 XX 团队,参与到 P 项目的迭代工作中。

我们 C 小组大约有 7 个开发,前端有 4 个。

背景

P 项目早在 18 年就启动了,我参与迭代的时候,其已经相当的成熟。

P 项目实现的是一个 B 端商城,服务于全球各类伙伴公司的采购、售后以及其它信息沟通,大到国包、省包、各级渠道商,小到各地零售门店。

P 项目连接的上下游系统非常的广泛,涉及仓库、商品、订单、客户、营销政策、激励等

项目规模十分宏大,整个部门围绕它划分了 4 个组,分别负责大客户、零售客户等。我们 C 组主要负责的是大客户这部分的业务功能。

我下边主要讲下整个前端项目的架构以及这部分业务。

业务模块

  • 系统管理站点

    • 卡片管理
      • 卡片注册
      • 卡片列表
    • 站点管理
    • 菜单管理
    • 权限管理
      • 用户管理
      • 角色管理
    • 国际化
    • 字典管理
  • 公共部分

    • 消息
    • 通知
    • 公告
    • 导入导出
  • 大客户站点

    1. 购物车
    2. 提交订单
    3. 我的框架
    4. 订单管理
    5. 订单确认
    6. 分批发货
    7. 送货预约(2 个前端)
    8. 退换货
    9. 地址分配
    10. 备案地址
    11. 我的客户
  • 大客户财经站点

    1. 发票核销(重度优化,组件拆分,业务逻辑整理)
    2. 激励对账(3 个前端)

项目架构

P 项目基于 Vue 2.0 + VueRouter 开发、webpack 打包,以 element UI 为基础的 yUI 组件库。应用基于卡片式架构,有自己的启动引擎,核心代码封装在 app.js。通常一个页面就是一个组件,用 webpack 以 umd 规范打包并混淆之后,上传到 CDN。运营端有一个页面设计器,用于构建前端页面,构建页面就是将卡片放进布局容器中。本人实现了一个简单的卡片式架构引擎,您可前往 Codepen 查看,演示链接:

https://000252617.codepen.website/card-style/?d=1618487271672#/

src 目录规划:

  • src/
    • shared/
    • cards/
      • site001/
        • component001/
        • component002/
        • component003/
      • site002/
        • component004/
        • component005/
        • component006/

对于每个组件目录,需要有一个 index.js 文件,暴露出组件配置对象:

import Component from "./card.vue"
export default Component

开发流程

  1. 创建菜单:url、权限、主题、等
  2. 创建卡片源文件:在 src 目录下新建 vue 组件
  3. 业务开发完成
  4. webpack 打包为 js 卡片资源
  5. 到运营端注册一个卡片,并上传卡片资源
  6. 设计页面:布局、卡片实例权限、页面权限、等
  7. 预览

核心概念

  • 应用(app):整个
  • 站点(group):由主题、权限、语言组成
  • 菜单:树形结构、用于站点导航,菜单项包含“布局”、“链接”、“节点” 3 种类型
  • 页面(page):挂在菜单的(布局)节点上
  • 卡片:注册到系统的组件文件,可在页面实例化,实例化之后称为卡片实例
  • 用户:用于访问 webapp 的站点的身份,可以是 w3 账号,也可以是 uniportal 账号
  • 权限:可以称为用户类型,用于限定站点、页面、卡片的访问
  • 用户权限:站点 + 角色 [+ 公司]
  • 菜单权限:针对角色,有权限方能显示
  • 页面权限:角色是否能访问到这个页面
  • 卡片实例权限:角色是否能访问到这个页面上的此卡片实例

我的业绩

  • 引入 TypeScript、为常用库添加类型声明、为 Vue 实例追加内置成员类型声明
  • 扩展了卡片构建系统,使之支持批量打包
  • 核心业务开发

问题以及思考

没有引入卡片版本控制机制

卡片一旦作为 js 资源存在,就脱离了 Git 版本管理。也就是说,Git 的分支或者标签在本项目中不能作为线上资源的标准。我们采取了人工管理手段,将本轮迭代的卡片等资源收集起来,然后以业务验收后的 SIT 环境为最终版本。

对于公共组件的更新,将涉及多张卡片的重新打包和发布,步骤繁琐

是的,卡片的构架优秀的一点就是,整个系统非常的松散,你可以迅速下架、更新某个页面,而不必打包整个系统,这非常棒。但是同时,我们所付出的代价就是,一旦某个公共代码块出现问题,我们必需打包所有对其有依赖的卡片,然后上传,这个操作之繁琐也是不争的事实。我们无法使用 CI / CD 进行持续的发布了。

作为思考

我认为可以对我们卡片追加版本控制系统,当我们发现卡片的源文件发生了变动,我们就可以启动 CI 系统对其自动打包,然后自动发布。当然,这个自动并非完全自动,我们必需确保变动是需要上线的。

这样,我们以仓库的某分支或者标签为上线基准,由此可以省却统计卡片资源的时间了。