React将引入Hooks,你怎么看?

更新日期: 2018-10-31阅读: 2.3k标签: hooks
来自:前端之巅(微信号:frontshow),译者:姚佳灵、无明,整理:覃云  


导读:

天啊!Bug 好多!地啊!头发好秃!妹啊!没空去撩!时间啊!哗啦啦流淌,难道你的一生就要被 Bug 缠住吗?难道就要当一辈子单身狗了吗?不!你的 Bug 将被 AI 拯救!
近日,据 MIT Technology Review 报道,一位名为“Repairnator”的机器人在 GitHub 上“卧底”数月,查找错误并编写和提交修复补丁,结果有多个补丁成功通过并被采纳,这位 Repairnator 到底是如何拯救程序员于水火的呢?
现代计算机程序非常复杂,在开发过程中不可避免地会出现 Bug,找到它们并编写补丁来进行修复是大部分程序员的日常工作。
但是,查找和修复 Bug 是一项需要耗费大量资源和时间的任务。研究人员已经开发出了不少能让修复 Bug 过程自动化的机器人,但是它们往往效率很低,或者只能产生一些质量低下的代码,反而会拖慢工作的进度。因此,开发人员非常希望能够依靠快速、高质量的机器人来搜索错误代码,并编写补丁修复这些错误。
就在不久前,瑞典皇家理工学院的研究人员宣称:该学院的软件技术教授 Martin Monperrus 及其朋友构建的机器人 Repairnator 经过测试和实验,已经可以发现错误并编写高质量补丁。


神秘用户 Luc Esape

如果不是特别关注,你或许根本注意不到 GitHub 上这个名为 Luc Esape(GitHub:https://github.com/lucesape )的用户,表面上看起来,这位用户就像是一位渴望在 GitHub 上做贡献的初级开发者,但是实际上,它的背后是 Repairnator 程序自动修复机器人。

“是的,我是个人造程序员”

Repairnator 的任务是在 GitHub 上扫描并修复一些代码的 Bug,开发者团队共进行了两轮测试,第一轮是在 2017 年 2 月到 12 月,Repairnator 在 14188 个 GitHub 项目的修复列表上运行并扫描错误,期间 Repairnator 总共分析了超过 11500 个失败的构建,其中有 3000 多个能被重现。然后,Repairnator 生成了针对其中 15 个问题的补丁,遗憾的是由于补丁质量低、花费时间过长等问题,这些补丁均未被接受。

第二轮测试是在 2018 年 1 月至 6 月,该团队没有具体说明他们对 Repairnator 做了哪些改进,但 Repairnator 在 1 月 12 日成功编写出了第一个被人类开发者接受的补丁。在之后的 6 个月里,Repairnator 陆续又有 5 个补丁被采纳。


>GitHub 上采纳了 Repairnator 修复建议的人类用户评论

至此,神秘用户 Luc Esape,或者说 AI 程序 Repairnator 成功发现并修改出了可被人类开发者接受的 Bug,那么问题来了:它到底是怎么做到的呢?


Repairnator 是如何工作的?

Repairnator 专门用于修复持续构建过程中出现的 Bug。它会持续监控被 Push 到 GitHub 上的数千次代码提交,并分析相应的构建过程。每一分钟,它都会启动新的修复尝试,以便在人类程序员之前修复 Bug。Repairnator 被设计为要尽可能快地提交修复,因为如果它能够比人类程序员更快找到并提交修复方案,那么我们就可以认为它可以与人类程序员相媲美。

下面通过一张流程图来看看 Repairnator 的工作流程:


Repairnator 的输入主要来自持续集成构建,当开发人员在 GitHub 项目提交代码的时候(a)就会触发(图中的上半部分(a)和(b))。 Repairnator 的输出包括两部分:(1)如果检测到持续构建的 Bug,则自动生成修复补丁(g);(2)收集有价值的数据用于未来的程序 Bug 修复和研究(h)和(k)。

Repairnator 会监控 GitHub 项目的所有持续性活动(c)。持续集成(CI)构建作为整个包含三个步骤的流程的输入:(1)第一阶段收集和分析持续集成构建的日志(e); (2)第二阶段在本地复现持续集成过程中出现的构建失败(f); (3)第三阶段运行来自最新学术研究的不同程序修复原型。

找到补丁后,Repairnator 会执行快速检查,以避免浪费开发人员宝贵的时间。如果经过检查后(i)确认补丁不会引入新的问题,则将其作为 GitHub 的拉取请求提交(j)给项目的原始开发者。接下来开发人员就会遵循他们通常的惯例进行代码审查和合并。

Repairnator 必须在特定的软件生态系统中才能运行。 由于我们在过去的研究项目中专业知识更偏向 Java,因此 Repairnator 的原型实现 更侧重于修复那些用 Java 编写的 GitHub 开源项目,这些项目一般都是基于 Maven 工具链和 Travis CI 持续集成平台构建的。


结   语

“你已经是个成熟的软件了,要学会自己调参修 Bug。”

这本来是一句网络上的段子,却在 AI 不断发展的今天,逐渐变成了现实。不过对于广大程序员来说,这绝对是一项福利,不用被 Bug 逼到头秃,节省出来的时间用来撩妹脱单,啧啧啧~ 简直不要太爽,不过在此之前,可能还得拜托各位研发人员,牺牲一些发量和撩妹的时间,让这一程序普及开来,解救更多被 Bug 所困的同胞吧!


链接: https://www.fly63.com/article/detial/1237

精通React今年最劲爆的新特性——React Hooks

你还在为该使用无状态组件(Function)还是有状态组件(Class)而烦恼吗?你还在为搞不清使用哪个生命周期钩子函数而日夜难眠吗?你在还在为组件中的this指向而晕头转向吗?这样看来,说React Hooks是今年最劲爆的新特性真的毫不夸张。

使用react hooks实现自己的context-redux

我们将userReducer函数返回的原始dispath命名为origin_dispatch,自定义dispatch函数,当action为函数的时候,我们执行action函数,并将origin_dispatch当作参数传进去;action不是函数,直接调用origin_dispatch,不做处理

useEffect Hook 是如何工作的?

使用useEffect 就像瑞士军刀。它可以用于很多事情,从设置订阅到创建和清理计时器,再到更改ref的值。与 componentDidMount、componentDidUpdate 不同的是,在浏览器完成布局与绘制之后,传给 useEffect 的函数会延迟调用。

React Hooks 你真的用对了吗?

从 React Hooks 正式发布到现在,我一直在项目使用它。但是,在使用 Hooks 的过程中,我也进入了一些误区,导致写出来的代码隐藏 bug 并且难以维护。这篇文章中,我会具体分析这些问题,并总结一些好的实践,以供大家参考

如何用 Hooks 来实现 React Class Component 写法?

Hooks 的 API 可以参照 React 官网。本文主要是结合 Demo 详细讲解如何用 Hooks 来实现 React Class Component 写法,让大家更深的理解 Hooks 的机制并且更快的入门。 注意:Rax 的写法和 React 是一致的

React-Hooks

以下是上一代标准写法类组件的缺点,也正是hook要解决的问题,型组件很难拆分和重构,也很难测试。业务逻辑分散在组件的各个方法之中,导致重复逻辑或关联逻辑。

React Hooks与setInterval

Hooks出来已经有段时间了,相信大家都用过段时间了,有没有小伙伴们遇到坑呢,我这边就有个 setInterval 的坑,和小伙伴们分享下解决方案。写个 count 每秒自增的定时器,如下写法结果,界面上 count 为 1 ?

React Hooks 底层解析[译]

对于 React 16.7 中新的 hooks 系统在社区中引起的骚动,我们都有所耳闻了。人们纷纷动手尝试,并为之兴奋不已。一想到 hooks 时它们似乎是某种魔法,React 以某种甚至不用暴露其实例

React Hooks实践

9月份开始,使用了React16.8的新特性React Hooks对项目进行了重构,果然,感觉没有被辜负,就像阮一峰老师所说的一样,这个 API 是 React 的未来。

用React hooks实现TDD

由于篇幅所限文章中并没有给出demo的所有代码,大家如果有兴趣可以将代码clone到本地从commit来看整个demo的TDD过程,配合文章来看会比较清晰,从进公司前认识了TDD,到实践TDD

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!