線上無小事，出現線上事故輕則影響用戶體驗，重則造成資損，這都是我們不愿意看到的現象。但又有一個著名的墨菲定律：可能出錯的事，就一定會出錯。那么我們應該如何減少錯誤、降低影響呢？

一、意識建設

1.1 質量重視

• 明確需求：需求或UE評審階段懸而未決的事情，及時找產品確認解決，保證不會有需求理解的偏差。避免開發聯調時臨時改邏輯，影響代碼質量
• 降低影響：公司重視線上 bug 是為了降低對線上用戶的影響，提供更好的服務，因此遇到線上 bug，應該第一時間修復以及降低影響，遇到問題，尋求協助，大家都有義務協助其他同學解決線上 bug
• 專項治理：定期排查 bug 集中的領域、子域、人員，進行專項治理
• 經驗學習：其他團隊分享沉淀、質量文化助手

1.2 開發容錯

• 字段處理：對字段的處理要謹慎，做好特殊字段值的處理。對于數組、對象類型的字段盡量不要相信后端的接口定義，最好做對空值和 undefined 的處理
• 編碼習慣
  • 文件大小：限制單文件、單方法的代碼行數
  • 代碼注釋：復雜邏輯多寫一些注釋或者記錄在技術文檔中，提升代碼可讀性便于問題排查和后續迭代
  • 規范命名：命名是代碼的自描述，優秀的命名將減少注釋量，甚至不需要注釋
  • TS 約束：完善的 TS 類型約束
• 迭代兼容
  • 對于迭代的需求，需考慮全面，比如老數據的兼容問題
  • 公共組件：兼容之前用法，改動后對于影響到的場景要全量回歸，每種類型回歸一種即可
  • 接口改動：新需求復用已有接口，需服務端提供接口出入參，并對當前所在環境做好自測

1.3 自測把關

• 排期規劃：理清需求點并與合作方確認疑問點，評估改動量和影響面，預留出回歸測試時間?；貧w測試按照正常開發標準，showcase 時盡量多確認到一些交互細節
• 自測 Check List：QA 測試 Case 留檔，技術文檔中列出本次開發所有的邏輯分支和特殊 Case（如精度等開發過程中覺得有風險的地方），自測完一條就中劃線劃掉，保證所有的邏輯都已自測
• 共用邏輯改動（組件/util）：梳理所有的調用方并與原開發同學確認影響面，統計不一樣的調用類型，將每種類型自測，再同步到 QA 同學，避免漏測
• 歷史用例：對于修改已有功能，回歸歷史用例；領域負責人，要把之前的測試用例積累下來，形成文檔，并整理對應測試場景的賬號、流程整理等

二、流程建設

2.1 領域分工

• 分工：明確領域第一負責人、第二負責人，盡量由熟悉領域的人修改代碼，如果是不熟悉的人修改了代碼，一定找負責人做代碼質量把關
• 積累：各領域的技術文檔整理歸檔

2.2 方案評審

• 對于復雜的需求，或者可能有質量隱患的需求，需要做方案評審，包含如何降低質量風險，暫時沒有強制規定，個人主動發起評審

2.3 Code Review

• CR 時機：
  • 提測前：保證修改后的代碼進入 QA 環節
  • 上線前：修改代碼一定重走涉及測試用例
• 強制 CR 機制：
  • 主要負責人：業務模塊負責人、公共函數/組件負責人、高危場景負責人
  • 核心、高危改動：公共函數/組件、高危場景

2.4 周會分析

• 線下 bug 納入統計，明確問題現狀、趨勢、分布等
• 每周線上線下 Bug 統計分析

2.5 問題復盤

• 線上 bug 徹底復盤，分析問題發生底層原因，形成可落地的改進機制，防止此類問題再次發生
• 典型的線下 bug，個人主動分享，形成最佳實踐，在組內推廣

三、技術建設

3.1 架構改造

• 微前端：子應用隔離，減小問題影響面和回歸難度
• 領域沉淀：完善領域模型與分層架構，降低代碼耦合度，降低維護難度

3.2 監控報警

• 接口返回值報警，比如 401、403、502
• JS 錯誤報警，比如 SyntaxError、TypeError
• 關鍵節點加埋點，比如文件下載后綴類型

3.3 自動化測試

• 單元測試：公共組件和函數盡量覆蓋，可以配合演示 demo，用例參考：https://github.com/umijs/umi-request/blob/master/test/util.test.js
• UI 測試：嘗試覆蓋主流程，減輕回歸成本
• 主動放火：自動走查所有頁面

3.4 主動反饋

• 用戶問題主動反饋，工單跟進
• 主動反饋與 DOM 錄屏、控制臺信息相結合，便于復原現場信息

總結

以上是生活随笔為你收集整理的关于前端研发质量提升的建设思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。