分析防範前端BUG

總結下前端bug

​​需求了解

原因

• 開發和産品對需求的了解不一緻
• 溝通一緻的需求有遺漏，後期忘做
• 沒有徹查子產品的依賴使用關系，錯估修改産生的影響範圍

對策

• 疑問或有不确定的及時與産品溝通
• 細小功能點不要後補以防忘記或者加到自己的 todolist 做完自測時再過一遍
• 修改代碼時多全局搜尋檢視引用的地方

前端基礎

• 基礎知識不足
  • 對循環，執行順序了解不夠
  • 全局對象使用不當，未及時重置
• 缺少異常處理
  • 接口異常處理未做
  • 接口傳回值判斷直接引用了可能是空對象的屬性

• 搬磚時了解一些基礎原理
  • 宏任務微任務等等
  • 自己整理下常用es文法
• 測試不同浏覽器下的狀态
• 遇到印象深刻的問題或者bug可以寫個部落格，做個筆記

代碼邏輯

• 邏輯複雜、函數太長
  • 一個函數做了多個操作
• 注釋不足難以閱讀了解
• ifelse分支太多
• 重複代碼多容易漏改
• 邊界考慮不足

• 函數拆分
• 能提煉出來的寫公共函數補足注釋(輸入輸出)
• 養成寫注釋的習慣
• 寫純函數
• ifelse優化
  • 單層時用switch替代
  • 多層時把易判斷的提前後return
• 代碼送出
  • commit日志盡量細點
  • 單個功能完成後就送出(日志就可以覆寫本次修改内容)
  • 不要複雜的功能合在一起送出
• 反問自己
  • 是否考慮了大部分情況
  • 自己下次改好不好改
  • 是否隔幾天依然能看懂自己的代碼
  • 是否易複用

接口管理

• 變動資訊未同步
• 錯誤估計修改影響範圍

• 變動可以記到自己的 todolist
• 要求對接的後端變動時通知自己
• 全局搜尋接口，确定變更影響的子產品

自測方法

• 操作習慣單一
• 邊界值測試不足

• 對照checklist
• A/B測試
• 邊界值
  • 空值情況
  • 單一狀态不同值：極小值>偏小值>引起UI變化的值>偏大值>極大值
• 不能隻滿足UI展現的情況(UI反映的隻是狀态的一種)
  • 特殊情況的展示需要UI補圖，及時提出需求或抛給産品
  • 文案：關注無文字、少文字、過多文字，不同浏覽器下顯示

思維方式

• 産品需求了解欠缺
• 使用者體驗了解不足
• 甩鍋思維

• 學會從産品角度了解需求
  • 必要性：影響範圍、對使用者有沒有用、體驗好不好
  • 難易度：功能複雜、邏輯複雜
• 使用者思維培養
  • 跳出開發人員的思路，把自己當小白去使用功能，了解使用者可能産生的困惑，進而明白産品設計的思路
• 場景思維
  • 把自己帶入産生需求的實際場景，可尋求産品的幫助，深度了解功能産生的緣由，了解公司産品的邊界，什麼能做，什麼不适合做
• 學習思維
  • 核心在于解決問題提升自己，不沉溺于甩鍋(都是一條船上的)
  • 保持一個開放接受容納的狀态，每個問題都是提升的機會
  • 做好記錄，PDCA 用起來
    • bug改完要記錄原因
    • 項目不忙或者結束後分析歸納bug原因(看你自己了)
    • 反思總結，找到問題根源，不會跌倒兩次
    • 定期提醒自己，check 一下