代码规范

  • JavaScript 相关：使用 eslint 和 vscode 的 config 强制配置
  • css：嵌套不能超过 4 层，良好的命名空间，命名一定是和组件和页面信息有关
  • git commit 强制规范
    • 新需求新建 git 分支，严禁修改 master 分支，需求分支应该第一步应该同步 master 最新代码
    • commitlint
    • husky


协作流程

A（BeforeMounting）：新需求诞生

  • 一般是 boss 和市场，运营等提出新需求

    B（Mounting）：产品评项目管理人员评审

  • 评审通过

  • 产品做出流程图和大概的规划

    C（Updating）： 产品拿着流程图和产品初稿和 UI，技术，测试讨论问题

  • 意见和讨论

    • 技术部分，提出可实现方案和最优解，
    • 是否可以复用页面和代码？前端做还是后端处理？用 X 技术还是 Y 技术？

  • 估算工期

    • 前端的部分，主要根据后端接口和 UI 出图的速度一般会滞后。
    • 比较大的项目至少要多留出 1/4 时间 估算，比如自己觉得一个月能完成，至少预估 35 天左右的时间。需求排期使用对应的日期排期工具（比如 asana 合理的排期可以检查哪一个环节除了问题）

      D（Render）: coding

  • 有问题及时反馈工作无论是技术问题，还是项目需求及时反馈到人对人

    • 产品需求，UI 设计对接到具体页面
    • 单元测试
    • 前后端对接接口
    • 和其他的部门的配合，申请其他的资源配合，跨部门的需求需要提前申请

  • 完成 coding 后需要做的事儿

    • code review (依赖 gitlab 和 vscode)
      • 提交 merge request（MR 标记项目需求文档，后端接口文档，UI 设计图等，让 review 的同事能清晰的知道你的项目具体在做什么）
      • 平级同事 code review（一般是在未完成的时候会提交主要的代码结构开始 review ，尽量在前期架构就开始提 review 的申请）
      • 使用 gitlab 的 Merge 功能 assagin 给对应的人，完成 review 以后，log 上对应的 label（
        • 比如reviewed【已完成 review 但是有问题需要需求人处理】
        • approved【没有问题，可以提交下一步代码】）
      • leader code reviw
      • review 后记：每周周会，花半小时，拿出这周 code review 发现的重点问题复盘一下。
    • 测试回测
      • 严格使用 jira
      • 修改 bug 后，应该及时提醒测试回测，以及重新 code review
    • UI 走查
      • 使用蓝湖和前端框架标准（AntDesign，bootStrap，Martrial 等设计框架）

    • 钉钉机器人 通知

      • 结合钉钉机器人在 coding 全程跟踪状态
      • 创建新分支提醒，合并提醒，上测试，上线提醒
      • assagin 给对应的人 code review 提醒，代码评论提醒等

        E（UnMounting）：上线

    • 上线审批流程

      • 提交合并代码的 MR —> master
        • 解决冲突
        • npm build 打包（创建最新包代码，生成最新版本，上传 CDN 资源）
          • 其中打包等过程都交给了 gitlab cli 自动化处理，首先写好脚本
        • 由前端项目负责人操作，权限一般在 leader 手上
      • 提交审批
        • 对应测试审批 【Y】
        • 对应运维审批 【Y】
        • 对应负责人审批 【Y】
        • 自己审批 【Y】
        • 完成上线 审批流程
    • 完成上线，线上回测
    • 随时修改线上 bugs

参考