{singhi}
🏷 tech
介绍我做过的项目 - P 项目
← • ☀ 🌙 • 💬 • 📅

从 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 系统对其自动打包，然后自动发布。当然，这个自动并非完全自动，我们必需确保变动是需要上线的。

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