blog icon indicating copy to clipboard operation
blog copied to clipboard

Published 20 hours ago • verified publisher icon HXWfromDJTU

工作规范沉淀 - 持续更新

Open HXWfromDJTU opened this issue 4 years ago • 0 comments

前言

不知不觉正式工作已经三年时间了，不同于自己的side-project，正式项目中更加强调流程化、标准化的工作规范。

比如淘系的《前端开发规约》，著名的雅虎35条军规等...学习参考固然重要，但能够沉淀下来成为自己的内容才更为重要。

本文会陆续补充自己在项目中犯过错，吃过亏的一些点，希望通过一次次脑海中的回荡，形成肌肉记忆...

交互

  1. 用户更改数据之后是否及时更新/拉取相关状态
  2. 实时性要求较高的数据，是否做了实施的更新请求。
    • 若采用轮询的方式，后端接口是否能够承受压力
    • 是否考虑使用ws
    • 实时更新数据，但网络不好的条件下。处理多个请求的返回，需要注意判断与当时的条件是否匹配。
  3. 重要操作都有防重复机制
    • 非幂等操作，诸如提现、转账等
  4. 如何决定提醒用户的层次
    • 是否过度打扰用户
    • 是否影响用户当前的主流程操作
    • 在轮询接口时，不要使用频繁弹出提示。(与请求一对一的提示是不必要的)
  5. 一个错误提示(弹窗)的关键要素
    • 用户理解为何出错的原因
    • 开发人员用于定位错误的错误码/错误信息
    • 对用户下一步的引导
  6. URL要尽量能表达页面的状态
    • 表单的条件状态要同步到URL中
    • 同步的时候必须要注意状态的数据流向，避免形成死循环
  7. 尽量缩短用户达到可交互时间的时长
    • 使用本地缓存，减少loading过程
    • 使用缓存初始化页面，然后静默更新，推动后端数据接口响应速度

代码逻辑

  1. API 请求都有错误处理

  2. 错误未被吞掉。

    • 本地日志
    • 主动上报日志
    • 使用 Toast、Dialog 通知用户

  3. 多个维度的逻辑相互交叉的判断时，要做到以下两点：

    • 不重复处理
    • 不遗漏处理

  4. 注释是否得当

    • 直译变量名的傻事不要去做
    • 特殊逻辑 关键逻辑 才需要添加注释

  5. 代码重复出现两次或以上，就有一定会有抽象的空间

  6. 内存管理

    • 计时器、时间监听，使用结束必须要记得清理

  7. 宁愿写面条代码，也不要将一处逻辑拆离地支离破碎

业务处理

  1. 对于货币decimal的处理
    • 在中心化业务下，建议食用大单位 带精度的值进行计算。而去中心化业务中，使用小单位 不带精度的值进行计算。
    • 需要在前端的几个数据来源入口处，把数据处理成统一的单位
      • 后端的数据接口
      • 用户的输入
      • 第三方SDK的计算结果
    • 在前端内部使用相同的计算单位，避免多次精度转换
    • 设计前端内部工具函数时，也参考上一条的计算单位

Vue.js

  1. 减少在watch中处理主业务代码
    • 因为其切面编写的原因，难以理清主要逻辑。
    • 建议使用在上报数据等场景下。
  2. 页面组件拆分
    • 注意横向拆分 和 纵向拆分相结合
    • 一个组件参数过多，意味着此次的组件拆分需要重新考虑
  3. 使用vuex中的请求缓存
    • 数据的请求与基本异常处理要在action中完成
    • 数据的缓存写入，有内部完成。对外提供是否强制更新缓存的参数。
    • 请求的结果以 [error, resData]的形式对调用方进行暴露

工程实践

  1. i18n
    • 每次提交代码之前，需要确认没有待翻译的中文出现。
    • 需要根据实际场景，抽取特性的翻译规则，便于翻译人员理解场景。
  2. git commit
    • 以单一功能为commit粒度，思维清晰，尽量不交叉功能提交
    • commit message必须要遵循 commit log的形。(这一点可以使用husky保证)
  3. pull request
    • 多人开发一个大feature时，需要单独开辟一个功能主分支
    • 为保证单个pr的代码量，单个feature没有完成的情况下也可以提交。后续开发基于此分支为主分支，开辟子分支继续开发。
    • pr的粒度应该维持在多个小commit(步骤/功能)所组成的一个小任务(修复一个bug,一个功能优化)等等
    • 在pr已经被同事review通过的情况下，合并前不要对该分支代码进行过大改动。
  4. git rebase
    • 在合并主分支之前，必须rebase主分支的代码
    • 在大feature合并到主分支时，commit过多时，建议使用git merge
  5. 不要依赖Code Review，自己在提交的前，必须做足开发测试。

项目管理

  1. 作为开发有立场，不要被产品前者走
    • 站在开发、项目进度的角度，要和其他角色进行bargin
  2. 能够自己闭环的小问题，尽量自己闭环掉，不要为了分工而分工
  3. 自己的工作任务也应该有缓存区，不能够随便来一个任务，就马上使用主线程进行处理
  4. 向上管理、向下管理、平级管理，永远要管理好别人的期望。有些内容不属于技术，但比技术更重要。
  5. 项目中发现的问题，没有调查就不要随便发言，模糊的结论要优于错误的结论。

to be continue....

参考文章

[1] 阿里前端开发规范

HXWfromDJTU avatar Oct 26 '20 16:10 HXWfromDJTU