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

一、意識建設(shè)

1.1 質(zhì)量重視

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

1.2 開發(fā)容錯

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

1.3 自測把關(guān)

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

二、流程建設(shè)

2.1 領(lǐng)域分工

• 分工：明確領(lǐng)域第一負責人、第二負責人，盡量由熟悉領(lǐng)域的人修改代碼，如果是不熟悉的人修改了代碼，一定找負責人做代碼質(zhì)量把關(guān)
• 積累：各領(lǐng)域的技術(shù)文檔整理歸檔

2.2 方案評審

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

2.3 Code Review

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

2.4 周會分析

• 線下 bug 納入統(tǒng)計，明確問題現(xiàn)狀、趨勢、分布等
• 每周線上線下 Bug 統(tǒng)計分析

2.5 問題復(fù)盤

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

三、技術(shù)建設(shè)

3.1 架構(gòu)改造

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

3.2 監(jiān)控報警

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

3.3 自動化測試

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

3.4 主動反饋

• 用戶問題主動反饋，工單跟進
• 主動反饋與 DOM 錄屏、控制臺信息相結(jié)合，便于復(fù)原現(xiàn)場信息

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。