谈谈前端产品质量控制

谈谈前端产品质量控制

近段时间一直在负责前端团队的通用技术产品，好比各种统计平台、通用脚手架、客户端工具等，这类工具的特色是用户数量相对较多，且易引发线上报错。接手这些工做以来一直是胆战心惊，尝试用一些方法让本身天天不用如此胆战心惊。

因而，工做中我有意地将部分注意力集中在 “如何保证前端产品质量？” 这个问题上。

实话实说，目前负责的产品质量方面的进展并无多大，探索这个过程须要时间，也须要试错。下面是我在实践过程当中的一些小技巧，仅供参考。

下文就从下面几个角度谈上面的问题：

• 代码质量
• 测试质量
• 运行质量
• 其余

代码质量

代码质量 ≈ 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

其余

这里主要说的是工具支持。

你们都很清楚，测试很是重要，但实际在公司产品运行过程当中，除了专业的测试人员外，开发人员自测涉及的：单元测试、测试覆盖率、持续集成、代码质量检查... ... 在不少团队并无彻底普及，主要缘由仍是由于比较麻烦。

并且不少工做都是重复性的，那么，是否能够经过工具帮助开发者快速的创建比较完整的质量监控手段呢，我认为是可行的，下一步也要作这样的工具。

完。