工作规范沉淀 - 持续更新

[HXWfromDJTU]

前言

不知不觉正式工作已经三年时间了，不同于自己的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] 阿里前端开发规范