谈谈前端产品质量控制

谈谈前端产品质量控制

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

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

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

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

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

代码质量

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

其他

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

大家都很清楚，测试非常重要，但实际在公司产品运行过程中，除了专业的测试人员外，开发人员自测涉及的：单元测试、测试覆盖率、持续集成、代码质量检查... ... 在很多团队并没有完全普及，主要原因还是因为比较麻烦。

而且很多工作都是重复性的，那么，是否可以通过工具帮助开发者快速的建立比较完整的质量监控手段呢，我认为是可行的，下一步也要做这样的工具。

完。