技术变化那么快,程序员如何做到不被淘汰?

11 月 24 日,TGO TALKS 的舞台迎来了 6 位经历过严格培训的 CEO、CTO、Team Leader 进行演讲。TGO TALKS 由 TGO 鲲鹏会组织,职业中、英文演讲培训师亲临现场,与参与者一起学习演讲的关键技巧,配合充分的练习和反馈,使大家在短时间内迅速提升了演讲功力,最后更有精彩的 TGO TALKS SHOW 。每位分享者按照演讲思维方法论,精心准备了 18 分钟的主题演讲,将从技术人的个人成长以及在时代变革中的定位、团队建设管理方法、创业技巧等方面,讲述当代技术人的知与识。

本文根据洛凯科技 Aladdin 项目负责人 & TGO 鲲鹏会北京分会会员王泰在 TGO TALKS 上带来的《未来的程序员 = 人工智能 + 软件工程》的演讲整理。王泰针对软件开发中 70% 的时间是在 debug 的问题,提出了通过人工智能和产品化方式解決问题的方法。以下为王泰现场分享内容,Enjoy:

口述 | 王泰
编辑 | Rainie Liu

大家好,我是王泰,来自于洛凯科技,目前是洛凯北京办公室的一名技术管理者,也是我司 Aladdin 项目的项目负责人。

今天,我的演讲会分成三个部分:

  • 今天的软件工程

  • 人工智能 + 软件工程

  • 新的挑战,我们选择?

在开始之前,我们先来思考三个问题:

  • 今天的软件工程,大家满意吗?

  • 我们能不能用人工智能的手段解决现在软件工程的问题,并且这样做会对我们自己的生活、工作产生多少影响?

  • 这也是我的一些个人的观点:面对未来不断变化的挑战,我们应该如何做出选择?

当前,软件已经深入到我们的工作和生活当中,大多数人都已经无法离开软件,可见当今软件普及程度有多高。那么请大家想想,我们的软件工程足够成熟了吗?

我相信,当我用反问的形式向大家提问时,大家的心中肯定有些许不安,开始思考当下软件工程是不是还没有那么成熟。可见大部分人的心中都没有明确的答案,都明白我们的软件工程还有许多可以改进的地方。

那请大家再设想一下,一份代码,从我们开发到交付需要经过 Coding、Testing、Debugging 的过程。我们每个写过代码的人都知道,一般来说,Testing 加 Debugging 的时间远远大于我们 Coding 的时间。

可是你们知道它们的时间分配比例是什么样的吗?

在《单元测试的艺术(第二版)》中,作者统计分析了 200 个研发 Case,得到如下结论:

总体来看,我们 Testing 和 Debugging 的时间,是 Coding 时间的 3 倍,甚至更多。

当你们看到这份数据时,是不是也回忆起自己坐在电脑前,痛苦 debug 的经历了呢?

就像上图这幅漫画展示一样,我们程序员的生活就是在不断地写 Bug 与修 Bug 中度过。

因为即使是优秀的工程师,他们也会面临着同样的问题——Testing 和 Debugging 的时间太长。而 Testing 和 Debugging 往往是最无聊、最令人讨厌的事情。

因为在做 Debugging 的大部分时间中,我们只是反复地点击鼠标、跟踪断点、定位问题。这些工作日复一日的折磨工程师,一点点扼杀工程师们的创造力。

可是工程师应该是当今最富创造力的一群人,怎么能把时间耗费在重复性如此之高的工作中呢?

在场的大部分人都做过工程师,而且你们一定都是非常优秀的工程师,所以我猜测你们都尝试过解决这个问题。也许通过“过程控制”,也许通过“软件架构”。这些做法都没有问题,方法的确可以保障“过程”和“结果”更加可控。

但是我们花费在 Debug 的时间,似乎并没有明显的减少。

现在,我再问一下,我们现在的软件工程足够成熟了吗?

显然没有。

我们需要更多更有效的手段来减少 Debug 的时间,减少代码缺陷,提高我们的工作效率,以及拯救程序员们日渐稀少的头发。

如果我们用人工智能,那么 Debugging 能更加智能吗?能让 Debugging 更自动化吗?能让我们写出效率更高、缺陷更少的代码吗?

我们可以先将 Debug 的过程分成两部分:

  • 第一部分是错误定位;

  • 第二部分是错误修复。

首先,我们主要聊聊错误定位的问题。

实际上,在很早之前就有人开始研究自动化错误定位。在没有使用人工智能之前,自动化错误定位的手段包括基于频谱的错误定位方式——SBFL、基于变异的错误定方式——MBFL 等等。

这些方法都是基于统计概率获得的结果,它们的效果和原理各不相同,有些方法原理简单执行速度快,但效果有限;有些方法相对准确率更高,可定位时间太长。

而且使用他们还需要一个前提——必须依赖单元测试的执行结果,因此这些方法还没有广泛应用。

当前,我们 Aladdin 项目团队希望能让所有的程序员都能体验上自动化错误定位的好处,使用上高效的错误定位手段,为此我们尝试去利用人工智能的方式改进错误定位的过程。

目前,我们结合了 Android 工程师工作的流程,在工程师调试时,实时给出代码的修改建议。

我们用人工智能的方法不仅缩短的错误定位的时间,而且也将准确率提高到 80%。同时,我们还正在尝试,让程序员们可以不写单元测试,就可以做错误定位。

实际上,人工智能在提高工程研发效率上能做的事情远不止这些。也许你们已经听说过人工智能现在正在学习如何改 Bug,甚至学习如何写代码。

上图是一段炉石传说的 Python 代码,这是北京大学软件工程实验室使用 CNN 的方式自动生成的代码。他们把卡牌上的描述文字输入到他们写好的程序中,接下来程序就可以自动分析卡牌描述被发动时的规则,并生成相应的 Python 代码。

虽然这段代码看上去像一个刚学编程的初学者写的,也不能全部正确运行,但是这已经离我们曾经设想过能自动写代码的程序非常接近了。

以上都是一些实际的落地场景,如果未来能有更多了解人工智能和软件工程的工程师一起加入进来,那么我们就可以推进更多的场景实现。

但是,我们的工程师现在还是每天陷入在写不完的 Bug 和 Debug 的困境中,并以为这些都是理所当然的工作。

科技的进步不会停止,我相信迟早有一天能自动写代码的程序时代会真正来临。那么,到时候我们会面临哪些挑战呢?我们又该如何解决挑战呢?

我想我们可以做 2 点:

  1. 拥抱变化;

  2. 终身学习。

过去,我们是传统行业的挑战者,经历过互联网对传统行业的冲击;我们曾经也是互联网红利的受益者,做过风口上的那只猪。然而,眼下我们面临的挑战似乎是来自于行业内部程序员之间的竞争。

实际上,未来整个工程行业都将面临来自于外部的挑战,而这个挑战这就是人工智能技术。当面对人工智能时,我们要转换自己的思维,我们应该主动学习人工智能,至少要了解人工智能会对我们的行业产生什么影响。

当前,虽然程序员之间的竞争也很明显,但是只要市场足够大,那么工作需求还是有很多的,这也是让很多人现在不愿意面对转型的原因。

我们身边有不少这样的程序员——他们每天都在做重复的工作,安于现状,没有学习的激情。同时,随着年龄的增长,他们开始产生焦虑,因为他们的能力和体力已经比不上新人,所以如果他们不能顺利转型管理,那么就会担心公司裁员。

最近,我有个朋友在向我抱怨,他开始担心自己未来缺少竞争力,不能负担起北京的生活成本。他已经开始考虑,是否要在近两年内换一个其他城市里压力小一点的工作。

当然,这只是个案。

可是,当人工智能真的可以写代码的那一天,那就是我们整个行业都要面临的挑战。

这就像是,互联网改变了通信行业;QRCode 改变了金融行业;而现在人工智能不仅会改变行业,更会改变程序员的工作方式。

过去,变化只是生活的一部分;现在,变化已经成为了生活的全部。

实际上,我的工作也一直在发生变化。最早,我是一名校内网的后端工程师,我在校内网写了 4 年半的主站后端代码。2012 年,我开始创业,被迫走向了管理岗位;后来,我接触到了 TGO 鲲鹏会,这是我第一次关键变化

这次的变化让我感受到“做好写代码之外的工作”和“写一段优美的代码”同样重要。

2015 年,因为企业的发展需求,我希望可以用机器学习给公司产品赋能。于是,我很快搭建起公司的推荐系统队伍,同时我也开始重新学习数学、算法。虽然我们的产品由于市场需求转型没有成功,但是那段时间我们团队积累了不少的技术方案,帮助公司在后续并购的过程中提高了估值。此时,是我第二次的关键变化。

在这次变化之后,我现在的工作已经离不开机器学习和人工智能。

今天,我想让自己开始第三次的关键变化。过去,我在自己的舒适区里做技术和科技管理者,不愿走到台前。因为我是一个非常容易紧张的人,每次走到台前都需要做巨大的心理建设。但是,现在的工作已经不太允许我一直躲在后面,所以我选择让变化驱动自己成长。

我想,我们每个人都应该拥抱变化,因为变化会影响到我们工作和生活的点点滴滴。

我们可以畅想一下未来程序员的工作——未来可能会有两种程序员,一种是写一份让机器读懂产品文档的程序员;另一种是开发和维护人工智能的程序员,他们既能懂得人工智能,又能懂得软件工程。

或许现在的程序员有部分会被人工智能取代,但是我相信,只要我们拥抱变化,不断地提高自己,那么这种变化一定可以驱使你不断进步!

现场精彩花絮
(0)

相关推荐