談談前端產品質量控制

近段時間一直在負責前端團隊的通用技術產品，比如各類統計平臺、通用腳手架、客戶端工具等，這類工具的特點是用戶數量相對較多，且易引起線上報錯。接手這些工作以來一直是膽戰心驚，嘗試用一些方法讓自己每天不用如此膽戰心驚。

于是，工作中我有意地將部分注意力集中在 “如何保證前端產品質量？” 這個問題上。

實話實說，目前負責的產品質量方面的進展并沒有多大，探索這個過程需要時間，也需要試錯。下面是我在實踐過程中的一些小技巧，僅供參考。

下文就從下面幾個角度談上面的問題：

• 代碼質量
• 測試質量
• 運行質量
• 其他

代碼質量

代碼質量 ≈ xxlint

除了代碼格式外，各類 lint（eslint、lesslint 等）可以幫助開發者發現不易察覺的代碼邏輯問題。

測試質量

• 單元測試保證

  無論是開源產品，還是內部產品，單元測試是產品可靠性的重要保證。

  在一些場景下，比如臨時的活動頁面，可能來不及做單元測試，投入產出比不高，沒有單元測試還可以接受。

  但一些通用產品或持續時間比較長的產品，非常建議添加單元測試。

• 持續集成

  github 等平臺均有免費的持續集成服務，每次修改代碼提交后可以自動運行各類檢測腳本。

  公司內網可根據自身情況處理。

• 測試覆蓋率

  除了單元測試，測試覆蓋率也是個重要的指標。單元測試了多少百分比的代碼，有哪些代碼還沒有測試到，通過各類覆蓋率工具可以輕松獲取。

  這對質量保證而言非常重要。

運行質量

全網通用的埋點腳本報錯了，頁面基本也就白屏了，這是不可接受的。

“未料勝，先料敗”，這句話同樣適用于 Coder。

我們需要在通用腳本運行時捕獲到各類錯誤，不至于因為它的報錯影響頁面的運行。

再具體一些，其實就是 “JavaScript 錯誤捕獲” 的方式問題。

try ... catch ... 是最常用的方案，好處很多，它能反映調用棧（部分瀏覽器除外）。

但 js 方法的觸發是基于循環、事件等方式觸發，不是定義即執行的，那么，在每個函數中都加上 try catch 的成本未免太大了。我們把通用邏輯抽離出來，改造原有函數，使之具有 try catch 功能。

代碼如下：

try.js

module.exports = function(fn, backupFn) {return function() {try {fn.apply(this, arguments);} catch(err) {console.warn('err: ', err);if (!backupFn || typeof backupFn !== 'function') {return;}var args = Array.prototype.slice.call(arguments, 0);args.unshift(err);backupFn.apply(this, args);}}; };

user.js

var fn = function() {console.log(a); // will throw error };fn(); // throw Error: a is not definedfn = tryjs(fn);fn(); // catched

其他

這里主要說的是工具支持。

大家都很清楚，測試非常重要，但實際在公司產品運行過程中，除了專業的測試人員外，開發人員自測涉及的：單元測試、測試覆蓋率、持續集成、代碼質量檢查... ... 在很多團隊并沒有完全普及，主要原因還是因為比較麻煩。

而且很多工作都是重復性的，那么，是否可以通過工具幫助開發者快速的建立比較完整的質量監控手段呢，我認為是可行的，下一步也要做這樣的工具。

完。

總結

以上是生活随笔為你收集整理的谈谈前端产品质量控制的全部內容，希望文章能夠幫你解決所遇到的問題。

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