利用NLP分析三大前端框架的GitHub Issue

译者按： 各大框架既有优点也有不足，且用且珍惜！

本文采用意译，版权归原作者所有

小编推荐：Fundebug专注于 JavaScript、微信小程序、微信小游戏，Node.js 和 Java 线上 bug 实时监控。真的是一个很好用的 bug 监控服务，众多大佬公司都在使用。



作为开发者，我们习惯于加入向 GitHub 这样的社区来寻求技术上的帮助。因此，我们不由地好奇对于最流行的前端框架，开发者们到底问了什么样的问题和发现了什么样的 bug。

为了回答这些问题，我们使用无监督语义理解的 AI 技术来分析 GitHub 上的 issue 标题。我们的目的是为了发现在这些开源项目的 issue 中是否有着特定的模式或者相关的概念。

我们上传了4 份数据到我们的Lang.ai系统。这 4 份数据分别对应 Angular、React、Vue 和将它们三者综合起来。

整个数据处理时间花了不到一个小时，最终输出一个可视化的  意图(intent)集合，并且通过语义聚合来表示它们之间的关系。

一个 intent 是指一组词汇表达了一个语义。在当前场景下，表示一组 issue 标题。

返回的结果如下：



接下来我们深入分析每一个数据集得到的结果。

Angular, React and Vue



分析结果

1. 你应当检查每一个 null 值



这些 issue 都包含了“Uncaught TypeError”的字段。这是我们发现的第一个，而且在 JavaScript 社区是非常常见的一个 issue。我们可以看到很多都是关于这样的报错，就像：Uncaught TypeError: Cannot read property 'name' of null. 我想应该考虑使用 TypeScript。

2. 输入的处理比想象中难



对于如何处理表单的问题我们在所有框架的 issue 中都有看到。它们要么和验证(validation)相关，或则在不该触发的时候触发事件，等等。事实上，每一个框架都有各自对于表单的工作方式：Angular, React, and Vue.

3. 都喜欢提新功能需求

在 Angular 的项目中快速查找feature request，会返回将近 5000 个结果。要知道，总共才 15k 的 issues。在 React 中占比约 20%，Vue 中约 10%。

4. 导入模块也不简单



有上百个 issue 都是这样开头的： Cannot find module. 。你知道如果找不到 https 模块，那么会出问题的：you are not able to find the https module.

5. 当修改了 NODE_ENV 之后并未达到预期的效果



这是那种在我的电脑上没问题的情况。我们已经看到很多 issue 和环境（开发/生产）相关。还有很多也提到了关于strict模式的，虽然和 Node 环境无关，不过在语义上相近。



分析要点:

1. 提到了很多关于文档的问题



“AIO” 是 Angular.io 的缩写，甚至有一个专门的面板来整理这样的问题。大约有 2.3K 的 issues 和它相关。

2. 需求提交占了主要比重

一个从 0 开始开发了很多年的项目，特别是还包含了 Angular 1 的 issue。

3. 路由也可能很复杂

With the Child Route intent we are getting issues like “Angular 2 child routes lost data”. There are other questions like “How to update parent’s variable from child’s component?”_._ Routing will give you some headaches, even with that kind of cross-browser issues (spoiler alert: turns out it was the OP fault, not the browser).

我们的结果数据中有Child Route这样的字段，与之对应的 issues，像“Angular 2 child routes lost data”。还有很多类似的问题，比如：“How to update parent’s variable from child’s component?”。路由有时候很头疼，甚至还会有跨浏览器兼容问题。最终发现  这个是操作问题，而不是浏览器问题。

4. 变化侦测机制仍然有问题

Angular 的变化侦测机制是整个框架的核心，尽管已经比 Angular 1 好了很多，但是依然会触发很多问题。



分析结果

1. 在 React 中处理输入  有多种方式



我们之前已经说过处理输入是一个比想象中难的问题。在开发 React 应用的时候，这是一个主要的头痛点。也许应该看看这个 think in React?.

2. 全都和 setState()有关

这个很容易解释：因为你要更新 UI 的主要方法，特别是处理事件或者服务器请求的时候。文档已经给出了相应的指示： 关于 pitfalls 和 anti-patterns的warns， 但是好像只有很少一部分开发者真的阅读了这些资料。

3. 服务器渲染也有相应的成本

你可以读一读这篇 博客, 服务端渲染的 React 应用可以提供一些好处，比如性能和 SEO。但是这些好处会导致一些资源耗费：比如整个应用的复杂性。比如展示一张图片都需要额外的工作。

4. 我们需要更多的属性(attribute)

我们  想要更多的属性，比如添加对 SVG 元素的支持，甚至iframe. 还有多少人在使用 iframes?



分析结果:

1. 再说一遍，处理表单的问题

尽管有很清晰并且详细的文档，但是好像使用 Vue 和 React 的开发者总是在处理输入上不愉快。也许他们应该看看这个：不同框架对比。

2. 小心对待计算出来的属性(Computed Properties)



可以在我们的分析结果中看出，issues 中提到和 cache,setter,和 dependency 有关的问题。

3. <Select> 元素非常微妙

虽然我们的分析结果中有很多关于输入的，但是关于<Select>元素的 issues 有很多。比如这样的：doesn’t select what was supposed to select.

4. 关于属性传递

我们通过属性值来传递数据，但是好像也会有一些问题。

我们是如何做到的？

获取数据

第一步是获取数据，幸运的是 GitHub 提供 API 和包供我们使用。我们使用了 Node.js 模块来处理@octokit/rest.

要注意 GitHub 把所有的 pull requests 都看作 issues，所以要做点区分。我们只是去分析真的 issues。然后我们获取每个 issues 的标题并保存下来。

最终的数据集包含了27.4k issue titles。它们来自: Angular(15k) (不是AngularJS), Vue(6.4k)和React(6k)。


const Promise = require("bluebird");
const fs = require("fs");
const octokit = require("@octokit/rest")();

octokit.authenticate({
    type: "basic",
    username: "USER",
    password: "PASS"
});

function handleGithubResponse(response, filename) {
    const data = response.data;
    data.filter(issue => !issue.pull_request).forEach(issue =>
        fs.appendFileSync(`${filename}`, `${issue.title}\n`)
    );
}

async function getIssueTitles({ owner, repo, filename }) {
    let response = await octokit.issues.getForRepo({
        owner,
        repo,
        per_page: 100,
        state: "all"
    });
    handleGithubResponse(response, filename);
    while (octokit.hasNextPage(response)) {
        response = await octokit.getNextPage(response);
        handleGithubResponse(response, filename);
    }
}

const repos = [
    {
        owner: "facebook",
        repo: "react",
        filename: "react-issues.txt"
    },
    {
        owner: "vuejs",
        repo: "vue",
        filename: "vue-issues.txt"
    },
    {
        owner: "angular",
        repo: "angular",
        filename: "angular-issues.txt"
    }
];

Promise.mapSeries(repos, getIssueTitles);

分析数据

当我们有了这些数据，在Lang.ai上创建项目: 包含所有的 issues。分析结果：针对三大框架的 issue 一起分析得出了 145 个意图(intents)，分别分析 Angular 153 个，React 86 个，Vue 78 个。

下一步

我们也可以将 issues 的评论和对话一起来分析，这将是另一个有趣的实验，不在本文的描述范围内。我们相信通过自然语言处理可以  帮助开发者打造更好的产品。比如帮助开发者  打造和改进聊天机器人，内容优化，文本分析等等。

关于Fundebug

Fundebug专注于JavaScript、微信小程序、支付宝小程序线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了80亿+错误事件。欢迎大家免费试用！

版权声明

转载时请注明作者 Fundebug以及本文地址：
https://blog.fundebug.com/2018/08/02/analyzed-github-issues-result/

您的用户遇到BUG了吗？

体验Demo 免费使用