技术变化那么快，程序员如何做到不被淘汰？
11 月 24 日，TGO TALKS 的舞台迎来了 6 位经历过严格培训的 CEO、CTO、Team Leader 进行演讲。TGO TALKS 由 TGO 鲲鹏会组织，职业中、英文演讲培训师亲临现场，与参与者一起学习演讲的关键技巧，配合充分的练习和反馈，使大家在短时间内迅速提升了演讲功力，最后更有精彩的 TGO TALKS SHOW 。每位分享者按照演讲思维方法论，精心准备了 18 分钟的主题演讲，将从技术人的个人成长以及在时代变革中的定位、团队建设管理方法、创业技巧等方面，讲述当代技术人的知与识。
本文根据洛凯科技 Aladdin 项目负责人 & TGO 鲲鹏会北京分会会员王泰在 TGO TALKS 上带来的《未来的程序员 = 人工智能 + 软件工程》的演讲整理。王泰针对软件开发中 70% 的时间是在 debug 的问题，提出了通过人工智能和产品化方式解決问题的方法。以下为王泰现场分享内容，Enjoy：
大家好，我是王泰，来自于洛凯科技，目前是洛凯北京办公室的一名技术管理者，也是我司 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 点：
- 拥抱变化；
- 终身学习。
过去，我们是传统行业的挑战者，经历过互联网对传统行业的冲击；我们曾经也是互联网红利的受益者，做过风口上的那只猪。然而，眼下我们面临的挑战似乎是来自于行业内部程序员之间的竞争。
实际上，未来整个工程行业都将面临来自于外部的挑战，而这个挑战这就是人工智能技术。当面对人工智能时，我们要转换自己的思维，我们应该主动学习人工智能，至少要了解人工智能会对我们的行业产生什么影响。
当前，虽然程序员之间的竞争也很明显，但是只要市场足够大，那么工作需求还是有很多的，这也是让很多人现在不愿意面对转型的原因。
我们身边有不少这样的程序员——他们每天都在做重复的工作，安于现状，没有学习的激情。同时，随着年龄的增长，他们开始产生焦虑，因为他们的能力和体力已经比不上新人，所以如果他们不能顺利转型管理，那么就会担心公司裁员。
最近，我有个朋友在向我抱怨，他开始担心自己未来缺少竞争力，不能负担起北京的生活成本。他已经开始考虑，是否要在近两年内换一个其他城市里压力小一点的工作。
当然，这只是个案。
可是，当人工智能真的可以写代码的那一天，那就是我们整个行业都要面临的挑战。
这就像是，互联网改变了通信行业； QRCode 改变了金融行业；而现在人工智能不仅会改变行业，更会改变程序员的工作方式。
过去，变化只是生活的一部分；现在，变化已经成为了生活的全部。
实际上，我的工作也一直在发生变化。最早，我是一名校内网的后端工程师，我在校内网写了 4 年半的主站后端代码。2012 年，我开始创业，被迫走向了管理岗位；后来，我接触到了 TGO 鲲鹏会，这是我第一次关键变化。
这次的变化让我感受到“做好写代码之外的工作”和“写一段优美的代码”同样重要。
2015 年，因为企业的发展需求，我希望可以用机器学习给公司产品赋能。于是，我很快搭建起公司的推荐系统队伍，同时我也开始重新学习数学、算法。虽然我们的产品由于市场需求转型没有成功，但是那段时间我们团队积累了不少的技术方案，帮助公司在后续并购的过程中提高了估值。此时，是我第二次的关键变化。
在这次变化之后，我现在的工作已经离不开机器学习和人工智能。
今天，我想让自己开始第三次的关键变化。过去，我在自己的舒适区里做技术和科技管理者，不愿走到台前。因为我是一个非常容易紧张的人，每次走到台前都需要做巨大的心理建设。但是，现在的工作已经不太允许我一直躲在后面，所以我选择让变化驱动自己成长。
我想，我们每个人都应该拥抱变化，因为变化会影响到我们工作和生活的点点滴滴。
我们可以畅想一下未来程序员的工作——未来可能会有两种程序员，一种是写一份让机器读懂产品文档的程序员；另一种是开发和维护人工智能的程序员，他们既能懂得人工智能，又能懂得软件工程。
或许现在的程序员有部分会被人工智能取代，但是我相信，只要我们拥抱变化，不断地提高自己，那么这种变化一定可以驱使你不断进步！
现场精彩花絮
更多精彩照片请点击详情。
加油吧，程序员们！
教练：我觉得你很棒！
TGO 鲲鹏会，是极客邦科技旗下高端技术人聚集和交流的组织，旨在组建全球最具影响力的科技领导者社交网络，线上线下相结合，为会员提供专享服务。目前，TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名，60% 为 CTO、技术 VP、技术合伙人。
会员覆盖了 BATJ 等互联网巨头公司技术领导者，同时，阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀，成为 TGO 鲲鹏会荣誉导师。