总结下前端bug
# 需求理解
# 原因
- 开发和产品对需求的理解不一致
- 沟通一致的需求有遗漏，后期忘做
- 没有彻查模块的依赖使用关系，错估修改产生的影响范围
# 对策
- 疑问或有不确定的及时与产品沟通
- 细小功能点不要后补以防忘记或者加到自己的 todolist 做完自测时再过一遍
- 修改代码时多全局搜索查看引用的地方
# 前端基础
# 原因
- 基础知识不足
- 对循环，执行顺序理解不够
- 全局对象使用不当，未及时重置
- 缺少异常处理
- 接口异常处理未做
- 接口返回值判断直接引用了可能是空对象的属性
# 对策
- 搬砖时理解一些基础原理
- 宏任务微任务等等
- 自己整理下常用es语法
- 测试不同浏览器下的状态
- 遇到印象深刻的问题或者bug可以写个博客，做个笔记
# 代码逻辑
# 原因
- 逻辑复杂、函数太长
- 一个函数做了多个操作
- 注释不足难以阅读理解
- ifelse分支太多
- 重复代码多容易漏改
- 边界考虑不足
# 对策
- 函数拆分
- 能提炼出来的写公共函数补足注释(输入输出)
- 养成写注释的习惯
- 写纯函数
- ifelse优化
- 单层时用switch替代
- 多层时把易判断的提前后return
- 代码提交
- commit日志尽量细点
- 单个功能完成后就提交(日志就可以覆盖本次修改内容)
- 不要复杂的功能合在一起提交
- 反问自己
- 是否考虑了大部分情况
- 自己下次改好不好改
- 是否隔几天依然能看懂自己的代码
- 是否易复用
# 接口管理
# 原因
- 变动信息未同步
- 错误估计修改影响范围
# 对策
- 变动可以记到自己的 todolist
- 要求对接的后端变动时通知自己
- 全局搜索接口，确定变更影响的模块
# 自测方法
# 原因
- 操作习惯单一
- 边界值测试不足
# 对策
- 对照checklist
- A/B测试
- 边界值
- 空值情况
- 单一状态不同值：极小值>偏小值>引起UI变化的值>偏大值>极大值
- 不能只满足UI展现的情况(UI反映的只是状态的一种)
- 特殊情况的展示需要UI补图，及时提出需求或抛给产品
- 文案：关注无文字、少文字、过多文字，不同浏览器下显示
# 思维方式
# 原因
- 产品需求理解欠缺
- 用户体验理解不足
- 甩锅思维
# 对策
- 学会从产品角度理解需求
- 必要性：影响范围、对用户有没有用、体验好不好
- 难易度：功能复杂、逻辑复杂
- 用户思维培养
- 跳出开发人员的思路，把自己当小白去使用功能，理解用户可能产生的困惑，进而明白产品设计的思路
- 场景思维
- 把自己带入产生需求的实际场景，可寻求产品的帮助，深度理解功能产生的缘由，理解公司产品的边界，什么能做，什么不适合做
- 学习思维
- 核心在于解决问题提升自己，不沉溺于甩锅(都是一条船上的)
- 保持一个开放接受容纳的状态，每个问题都是提升的机会
- 做好记录，PDCA 用起来
- bug改完要记录原因
- 项目不忙或者结束后分析归纳bug原因(看你自己了)
- 反思总结，找到问题根源，不会跌倒两次
- 定期提醒自己，check 一下
