一个程序员最重要的能力是什么？什么样的技能会让你在万千程序员中脱颖而出，成为老板眼中“能打”的程序员？是要熟背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万个球，学多少招式都没有用。
