談談前端產品質量控制

談談前端產品質量控制

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

因而，工做中我有意地將部分注意力集中在 「如何保證前端產品質量？」 這個問題上。

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

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

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

代碼質量

代碼質量 ≈ 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 defined

fn = tryjs(fn);

fn(); // catched

其餘

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

你們都很清楚，測試很是重要，但實際在公司產品運行過程當中，除了專業的測試人員外，開發人員自測涉及的：單元測試、測試覆蓋率、持續集成、代碼質量檢查... ... 在不少團隊並無徹底普及，主要緣由仍是由於比較麻煩。

並且不少工做都是重複性的，那麼，是否能夠經過工具幫助開發者快速的創建比較完整的質量監控手段呢，我認爲是可行的，下一步也要作這樣的工具。

完。