我国最大的IT项目管理门户网站,国内IT项目管理培训与咨询服务提供商

当前位置:首页 > 人物访谈 > 正文

太多企业只做敏捷表面功夫——专访《重构》和《软件工艺》译者熊节

2019-12-26 来源:极客学院
一个程序员最重要的能力是什么?什么样的技能会让你在万千程序员中脱颖而出,成为老板眼中“能打”的程序员?是要熟背LeetCode题目?是要破解冷门高深的技术难点?还是要能够手写代码?
显然,都不是。尽管上面提到的这几点,是国内技术面试经常会遇到的问题,但它们跟你工作之后是不是真的能有高效、有用的产出,根本没什么关系。
实际中程序员们90%的时间都在写普通的软件,应对普通难度的技术问题。这时,真正决定你的水平高低的,是你在使用什么样的工作方式干活、你业余用什么方法提升自己。
TDD(测试驱动开发)就是这样一种能够提升工作产出的方法。据著名的敏捷教练、TDD专家熊节老师介绍,使用TDD模式开发和训练,开发效率甚至可以有10倍的提升。
TDD如何做到这一点?
带这这个疑问,极客学院采访了熊节老师,请他分享了关于敏捷、关于TDD、关于程序员能力提升的一些话题。

《重构》和《软件工艺》译者熊节老师
 
【嘉宾简介】
熊节,曾就职于全球顶级软件设计企业ThoughtWorks,担任总监咨询师。注重工程技术实践的极限编程(XP)方法,亲身参与华为、中兴、上海贝尔等企业的敏捷转型历程。《重构》、《实现模式》、《软件工艺》译者,在数十万程序员中产生广泛影响。
【采访实录】
极客学院:先请熊节老师给大家分享一下您的近况,最近在忙些什么?
熊节:最近跟技术有关的就是在做“程序员练功房”这件事。因为感觉整个行业来说,基本功都太差了,所以把那些高大上的东西都放一放,先做一些技术普及的东西。包括跟极客学院合作的实战营,还有我自己维护的一个小的练功房,写的文章也是跟开发和技术相关的,回到最基本的东西。从去年翻译完《重构》的第二版以后就开始做这些基础的工作。
极客学院:敏捷开发的理念进入中国已经有十多年了,您也一直是敏捷方面的布道者,就您了解来看,目前国内IT企业和技术团队对敏捷的应用情况是怎样的?
熊节:整体的来说,能够接受敏捷理念的企业和团队越来越多,这是一个好的现象。现在大量的企业愿意说我们用的是敏捷的方法,或者表示我们要用敏捷的方法。这种采纳的姿态跟以前是有很多不同的。
以前行业对敏捷是不太认可的,会有“敏捷是牛仔式开发”、“只适合小团队”、“不写文档”等等说法。现在越来越多的团队、组织、机构对敏捷是认同的。
另外一个方面,其实绝大多数企业口头上说“我们要敏捷”,表面上做一些功夫,但是敏捷内核的东西,比如TDD持续集成,这些最内核的东西他不做,敏捷就会流于形式。最近有个词叫“僵尸Scrum”,这种流于形式的敏捷现在是非常非常普遍的。十之八九的团队都在做这种表面的、流于形式的、没有什么效果的敏捷。
极客学院:您觉得造成这种现象的原因是什么?
熊节:因为敏捷内核的基本功不到位,这是很大的一个问题。
要讲大的原因的话,有一个时代背景。我们这个行业前面十几年是高速发展。高速发展的行业的人才一定是供不应求,对人才就没有什么挑选的余地,随便什么人才抓进来就用。
另外一个方面,过去十几年的软件工程的舆论导向、思想导向也有很大问题。从2001年开始,软件工程就讲“软件蓝领”。就是少量的人设计,大量的人是蓝领。蓝领不需要什么技术能力。当时故事传言说高中生培训几个月就可以写代码。行业存在软件开发去知识化、去技能化的导向:认为软件开发这件事是不需要什么专业的技能,不需要很高的能力的。这就导致整个行业对于“软件开发是什么”这个问题就缺乏认识,大家也不投入精力去建设这个能力,也就导致现在整个行业里面大家能力是普遍的缺失。
现在整个行业有放缓的趋势。那行业放缓了之后是不是说供大于求,我们就能招到优秀的程序员了呢?也不是。因为整个行业大家没有建设这个能力。
总结来说,有时代背景,也有过去软件工程造的孽,错误的导向给这个行业造成了深远的影响。
极客学院:对于敏捷的错误认识,可能不只是企业里有。很多程序员只专注于自己的技术方面的提升,觉得选择什么开发模式是公司的事情,跟自己没有太大关系,所以个人学敏捷相关知识的动力不强。您认为个体的程序员了解敏捷有哪些好处呢?
熊节:首先说,个人在时代的浪潮当中,主要是被引导。有个导向的问题就是看企业招聘。现在招聘面试考核的内容不是在考程序员能不能干,考的都是一些知识点。比如网上流传的阿里的技术面试题,他就考你JVM的细节啊、高并发啊这些东西。其实这些不是一个程序员每天工作做的事,不是程序员开发效率的体现。既然企业招聘的时候看这些东西,那么程序员在做自己能力建设的时候就会建设这些东西,他就会去刷题,就会去背算法,至于这些东西一年到头开发到底用几回,无所谓。
如果有一个程序员他开始意识到,我每天的工作是什么,我的基本功(如何),对我开发效率有影响的事情是什么。我们讲:理解需求、拆分任务、编写测试、高质量的代码实现——所有这些动作能够很快的做出来。这五个要素很少有企业去考他。
但是如果程序员自己意识到了这些东西很重要,去练习这方面的能力,他就会在这个团队中鹤立鸡群。他做的工作会更快、更好。
这会带来什么效应呢?别人会看到这个人价值很大。比如我2013年培养的毕业生,在我这培养了1年,他就可以去某知名大公司做咨询,去教该公司那些号称有多少年经验的程序员怎么做软件,这些老程序员还很服他。在我这工作3年,这家大公司出高薪去挖他,结果还没挖动。所以这个对个人价值的提升是非常明显的。
极客学院:那TDD和敏捷是什么关系呢?
熊节:我们看极限编程最早的时候网站上有一个图,显示这些敏捷实践之间的关系。测试驱动开发一直在最核心的位置。
一个绕不开的简单的核心问题,敏捷讲“我们要更快的速度迭代,我们要更频繁的生产出可工作的软件”,敏捷宣言讲“可工作的软件重于面面俱到的文档”。那我怎么不断地基于可工作的软件去交流呢?肯定我需要更频繁的发布,更频繁的交付。这带来一个问题就是你要怎么做软件质量的保证。
以前我们软件质量保障是靠测试人员手工去点,手工回归。三个月发布一次你可以手工测试,如果你每周发布一次,让测试人员跟在后面手工回归那是不可能的。要么把测试人员累死,要么软件质量一团糟,也有可能两件事情同时发生。
我在《敏捷中国史》这本书里讲到过这个故事:当时阿里妈妈的团队,钉钉的团队,他们就是真实遇到这个情况。因为他每周都要发布一个内测版本,他的测试团队是不可能跟得上的,所以开发团队就必须要自己做测试。如果开发团队不自己做高覆盖率、可靠的测试,他不可能迭代,不可能频繁的发布。我在知乎上答了一个题,他问“什么是中华田园敏捷”?我说我知道“伪敏捷”是什么样:一切没有高覆盖率、可靠的、完全自动化的测试的敏捷都是伪敏捷。你要知道一个团队是不是真的敏捷,你就让他把单元测试覆盖率拿出来看。覆盖率60%以下你就是伪敏捷。所以说,TDD是必不可少的核心。
极客学院:实际工作中,团队要求用TDD,但是程序员觉得写测试用例麻烦,他可能会先写生产代码,然后再补测试用例,这种情况也是存在的。
熊节:你如果真的到企业里面去观察,你会发现,“我先写完生产代码再补测试”是停留在口头上的。领导来问你,你为啥没写测试?为啥我们测试覆盖率这么低?他说:我们先赶工,我们赶完了再补测试。你要去观察,这个“回头补测试”的事情很少发生的。绝大部分情况他说完这个话然后就过去了。你说我下个月补测试,下个月又有下个月的项目,然后这个事情就这么推掉了。
实际的情况是补测试这个事情很少发生的。都停留在口头上说一说。这就是为什么要说“测试先行”,因为你要有这么一个规格,必须要先写测试。你不先写测试,这个测试不会写出来的。回头补这个事情操作起来也非常困难,因为你写代码的时候不是测试驱动的,那你补的时候就会发现这个测不动,出现很多的问题。就又会回到第一个现象上,就是我本来有两天时间用来补测试,一补发现补不进去,那算了吧太累了,干点别的吧。补测试又停留在口头上。
我们现在空对空地讨论,说我有方法A和方法B:方法A是我先写测试,方法B是我先写功能,再写测试。大家开始讨论是A比较好呢?还是B比较好呢?但是你真的到一线里面去看一看,这个方法B根本就没有发生过。实际做的时候它是落不了地的。
极客学院:所以您认为推进TDD的应用更多的还是要靠制度或者说领导层的要求?
熊节:我觉得任何一个工程实践都一样。一方面是制度要求,一方面是能力。他没有能力,他就不会(这么做)。他没有这个能力,你考核他会怎么样呢?他就告诉你做不了。
一个团队里面10个人,有1个人说我做不了,领导说你做不了你学,别人怎么做你跟他学。但现在我们的情况是,8、9个人全都做不了。这就回到我前面说的问题,这个能力是普遍缺失的。领导不懂啊,领导一看全都做不了,那就是这个事不切实际,于是就不用做了。这是我们企业里存在的真实情况。领导认为这个落不了地。
所以我的观点是,制度、领导要求,这个是很重要的,但是必须要有配套的能力。如果你认为只要有制度这个事情(单元测试)就能实现的话,你就等于还是认为这个事不需要能力、不需要技术。软件开发是对人的能力要求很高的事情。
极客学院:现在也有一些专家和资深程序员意识到了TDD落地中的问题,比如有人提出了一种变通,叫做TPDD(测试计划驱动开发),您怎么看?
熊节:这要看测试计划是一个可执行的软件还是只是一个文档。我们看到太多太多的案例了,写了很多的文档,什么设计文档、计划文档、测试用例文档,你要到真正运行起来看。软件运行起来,是唯一有说服力的。如果他是一个可执行的软件,那他就是测试驱动开发。
极客学院:您对BDD(行为驱动开发)、ATDD(验收测试驱动开发),怎么看?TDD在其中有何优势?
熊节:无非就是说我写的不是单元测试,是对整个功能的测试。我觉得这个很好,当我要接受一个需求的时候,给我一个整体的描述,这个很有价值。但是他替代不了TDD。这是一个颗粒度的问题。它(BDD/ATDD)可能是我在写一个feature的时候,我可能要一天两天才能最后让它通过。但是TDD的用例是,我写一个用例,10分钟之内让他通过,然后再写一个用例。这是开发的步伐。它们之间只能说是互补的关系,不是替代的关系。
并且我认为TDD是核心,因为没有TDD的话,整个反馈周期会很长,其它的东西都会执行起来非常困难。
极客学院:在跟极客学院合作的第二期TDD实战营中,主要对标什么过程,适合什么人群,能达到什么预期效果,能否举一个在工作场景中应用的案例?
熊节:我的目标很明确,就是一线的软件开发人员。我们这个行业里很多一线软件开发人员的能力之差,是令人发指的。整个行业一线,几乎所有人水平都很差。
第一期的实战营里有一个题目,解析命令行的参数。这个题目我认为合理的情况,一个程序员第一次接触这个需求是在1~2个小时完成。但是我看到很多的人,4、5个小时完不成,7、8个小时完不成。最夸张的,有一个人他给我预估的完成时间是两个星期。这就是我们这个行业里的现状。整个行业,几乎所有人能力都非常非常差。
我想做的事情就是,第一,通过这个实战营,能让大家看到,基本能力是有很大的差距的。第二,我想建立一种刻意练习的环境。有兴趣的人他能进来开始这些练习。我也看了很多的这种在线培训、网课,90%的网课都走偏了方向。因为培训是没有用的。我通过听别人讲课我是学不到任何东西的。一个人唯一能学到东西的方法就是我要自己练,反复的练习。练自己不熟悉的东西,得到别人的反馈。这是你唯一学东西的法宝。
你听别人讲,讲多少个小时,你听完好像知道了,其实啥也不知道。所以我实战营的宗旨就是,我不讲课,你来就是来练习的。我给你创造一个刻意练习的环境,大家可以来练。
练出来的效果在我来看很明显。第一期实战营最后一道题,有个一学员,第一次花了4、5个小时,到最后,他可以30分钟就把这道题做完。这就是10倍的效率提升。这些能力都是通过反复的练习得到的。
因为我们这个行业基础太差了,所以经过一段时间的刻意练习,开发的速度有个10倍的提升太正常了。
极客学院:最后一个问题,作为资深技术人,关于技术人如何快速提升自己的能力,您有什么心得分享?
熊节:一切的能力都是靠练出来的。很多人没有明白这个事情。公司也好,程序员也好都没有明白这个问题。找个人给你上一天课,听老师讲课听的很开心,没有任何用。唯一有用的就是练习。要想长本事,要想提高能力,微信群里面聊天没用的,参加培训没用的,听网课没用的,看书也不怎么有用,只有练。非常艰苦的练习。
我经常引用的就是《灌篮高手》安西教练的话:“投2万个球吧。”你没有投2万个球,学多少招式都没有用。
分享到:

免责声明:
  1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的,并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请浏览者仅作参考,并请自行核实相关内容。
  2、本站部分内容转载于其他网站和媒体,版权归原作者或原发布媒体所有。如文章涉及版权等问题,请联系本站,我们将在两个工作日内进行删除或修改处理。敬请谅解!

延伸阅读:

more

会议活动

more

公开课

more

PMO

Copyright © 2020 IT项目管理界 版权所有 京ICP备17062359号-4 如转载本站文章,请注明原作者和原发布媒体

本着互联网分享精神,本站部分内容转载于其他网站和媒体,如稿件涉及版权等问题,请联系本站进行删除或修改处理

客服电话:010-89506650 89504891 非工作时间可联系:18701278071(微信) QQ在线:511524637

新闻与原创文章投稿:tougao#cpmta.com 客服邮箱:info#cpmta.com(请将#换成@)

IT项目管理界——我国最大的IT项目管理门户网站,隶属卓橡公司

IT项目管理界官方微信

IT项目管理界官方微信

PMO大会官方微信

PMO大会官方微信