总结下前端bug

• ​​需求理解
• 前端基础
• 代码逻辑
• 接口管理
• 自测方法
• 思维方式

# ​​需求理解

# 原因

• 开发和产品对需求的理解不一致
• 沟通一致的需求有遗漏，后期忘做
• 没有彻查模块的依赖使用关系，错估修改产生的影响范围

# 对策

• 疑问或有不确定的及时与产品沟通
• 细小功能点不要后补以防忘记或者加到自己的 todolist 做完自测时再过一遍
• 修改代码时多全局搜索查看引用的地方

# 前端基础

# 原因

• 基础知识不足
  • 对循环，执行顺序理解不够
  • 全局对象使用不当，未及时重置
• 缺少异常处理
  • 接口异常处理未做
  • 接口返回值判断直接引用了可能是空对象的属性

# 对策

• 搬砖时理解一些基础原理
  • 宏任务微任务等等
  • 自己整理下常用es语法
• 测试不同浏览器下的状态
• 遇到印象深刻的问题或者bug可以写个博客，做个笔记

# 代码逻辑

# 原因

• 逻辑复杂、函数太长
  • 一个函数做了多个操作
• 注释不足难以阅读理解
• ifelse分支太多
• 重复代码多容易漏改
• 边界考虑不足

# 对策

• 函数拆分
• 能提炼出来的写公共函数补足注释(输入输出)
• 养成写注释的习惯
• 写纯函数
• ifelse优化
  • 单层时用switch替代
  • 多层时把易判断的提前后return
• 代码提交
  • commit日志尽量细点
  • 单个功能完成后就提交(日志就可以覆盖本次修改内容)
  • 不要复杂的功能合在一起提交
• 反问自己
  • 是否考虑了大部分情况
  • 自己下次改好不好改
  • 是否隔几天依然能看懂自己的代码
  • 是否易复用

# 接口管理

# 原因

• 变动信息未同步
• 错误估计修改影响范围

# 对策

• 变动可以记到自己的 todolist
• 要求对接的后端变动时通知自己
• 全局搜索接口，确定变更影响的模块

# 自测方法

# 原因

• 操作习惯单一
• 边界值测试不足

# 对策

• 对照checklist
• A/B测试
• 边界值
  • 空值情况
  • 单一状态不同值：极小值>偏小值>引起UI变化的值>偏大值>极大值
• 不能只满足UI展现的情况(UI反映的只是状态的一种)
  • 特殊情况的展示需要UI补图，及时提出需求或抛给产品
  • 文案：关注无文字、少文字、过多文字，不同浏览器下显示

# 思维方式

# 原因

• 产品需求理解欠缺
• 用户体验理解不足
• 甩锅思维

# 对策

• 学会从产品角度理解需求
  • 必要性：影响范围、对用户有没有用、体验好不好
  • 难易度：功能复杂、逻辑复杂
• 用户思维培养
  • 跳出开发人员的思路，把自己当小白去使用功能，理解用户可能产生的困惑，进而明白产品设计的思路
• 场景思维
  • 把自己带入产生需求的实际场景，可寻求产品的帮助，深度理解功能产生的缘由，理解公司产品的边界，什么能做，什么不适合做
• 学习思维
  • 核心在于解决问题提升自己，不沉溺于甩锅(都是一条船上的)
  • 保持一个开放接受容纳的状态，每个问题都是提升的机会
  • 做好记录，PDCA 用起来
    • bug改完要记录原因
    • 项目不忙或者结束后分析归纳bug原因(看你自己了)
    • 反思总结，找到问题根源，不会跌倒两次
    • 定期提醒自己，check 一下