分析防范前端BUG

总结下前端bug

​​需求理解

原因

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

对策

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

前端基础

原因

  • 基础知识不足

    • 对循环,执行顺序理解不够
    • 全局对象使用不当,未及时重置
  • 缺少异常处理

    • 接口异常处理未做
    • 接口返回值判断直接引用了可能是空对象的属性

对策

  • 搬砖时理解一些基础原理

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

代码逻辑

原因

  • 逻辑复杂、函数太长

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

对策

  • 函数拆分
  • 能提炼出来的写公共函数补足注释(输入输出)
  • 养成写注释的习惯
  • 写纯函数
  • ifelse优化

    • 单层时用switch替代
    • 多层时把易判断的提前后return
  • 代码提交

    • commit日志尽量细点
    • 单个功能完成后就提交(日志就可以覆盖本次修改内容)
    • 不要复杂的功能合在一起提交
  • 反问自己

    • 是否考虑了大部分情况
    • 自己下次改好不好改
    • 是否隔几天依然能看懂自己的代码
    • 是否易复用

接口管理

原因

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

对策

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

自测方法

原因

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

对策

  • 对照checklist
  • A/B测试
  • 边界值

    • 空值情况
    • 单一状态不同值:极小值>偏小值>引起UI变化的值>偏大值>极大值
  • 不能只满足UI展现的情况(UI反映的只是状态的一种)

    • 特殊情况的展示需要UI补图,及时提出需求或抛给产品
    • 文案:关注无文字、少文字、过多文字,不同浏览器下显示

思维方式

原因

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

对策

  • 学会从产品角度理解需求

    • 必要性:影响范围、对用户有没有用、体验好不好
    • 难易度:功能复杂、逻辑复杂
  • 用户思维培养

    • 跳出开发人员的思路,把自己当小白去使用功能,理解用户可能产生的困惑,进而明白产品设计的思路
  • 场景思维

    • 把自己带入产生需求的实际场景,可寻求产品的帮助,深度理解功能产生的缘由,理解公司产品的边界,什么能做,什么不适合做
  • 学习思维

    • 核心在于解决问题提升自己,不沉溺于甩锅(都是一条船上的)
    • 保持一个开放接受容纳的状态,每个问题都是提升的机会
    • 做好记录,PDCA 用起来

      • bug改完要记录原因
      • 项目不忙或者结束后分析归纳bug原因(看你自己了)
      • 反思总结,找到问题根源,不会跌倒两次
      • 定期提醒自己,check 一下
上一篇:npm与yarn怎么选


下一篇:ajaxFileUpload+struts2多文件上传(动态添加文件上传框)