今天，给你推荐一门争议不断几近失传的武功秘籍

先打个招呼，我要介绍一个老朋友，熊节，在 ThoughtWorks 我们亲切称之为大熊。

介绍他的重要原因是，从“大学肄业”到 ThoughtWorks 总监咨询师，从业 18 年，他倡导的敏捷开发影响了包括我在内的一代程序员，也是我在 ThoughtWorks 里一直学习的榜样，我能加入 ThoughtWorks，也是深受大熊等人的影响。

我加入 ThoughtWorks 已八年有余，做过全栈开发、架构、TechLead、咨询、EA、中台……但我始终认为这八年 ThoughtWorks 教给我最大的价值的东西就是两个，一个是重构一个就是 TDD。

TDD 教会了我以终为始、目标驱动，重构教会了我持续演进、精益求精。

这些思想和技巧，不光影响了我编程的过程，还渗透到了之后咨询、架构、大规模架构重构、企业架构、数字化转型、中台等各个领域各个维度。在刚刚大熊翻译出版的《重构》第二版中，我和同事一起总结的“重构十六字心法”也非常荣幸的被大熊采纳到了序言之中。

所以今天郑重的为大家推荐一门熊节的关于 TDD 的课程，要知道在我们 ThoughtWorks 内部，也很少有人有机会能听到熊节的 TDD 课的，机会难得，强烈推荐。

什么才是程序员的核心竞争力？如何提高开发效率？2800 字，强烈安利给工作 8 年以下的程序员，剩下的内容就交给大熊……有请。

【熊节原创】

当年我们开发一款安卓 APP，用测试驱动开发的方式，不需要真机、不需要模拟器，在 JVM 上直接跑，180 秒跑完 2000+个测试用例，平均每 0.09 秒跑一个，我们下班回家老婆孩子热炕头时隔壁的大哥们还在写 Bug。

这个事情发生在 2014 年，也让我有了一个新思考。

第一，站在个人角度，在 996 大环境下，程序员的核心竞争力到底是什么？

看的人多、时间长就能发现规律，1-3 年求发展，3-5 年求跳槽，5 年以上求破瓶颈。我觉得核心解是开发效率。

我不知道这些场景有多少人遇到：

1.拿到一个需求，琢磨半天想不明白如何分解，不知道怎么下手；

2.一开始代码没测试，上线后，经常半夜被抓来处理问题，不要问我代码有没有坑，我自己也不知道；

3.新功能要改动一块老代码，不敢轻易下手改，每做点修改都很害怕。

开发效率低，要么低在需求上，要么低在质量上。很多朋友在后台留言，其实就是一句话：为啥我的开发效率低？

我觉得原因是观念停滞，方法陈旧，但求偷懒。

现在有一个误区，各大企业面试，比如流传的阿里技术面，他就考你 JVM 的细节啊、高并发。他并不是一个程序员日常开发效率的体现。

我们就会去刷题、背算法，至于这些东西一年到头用几回，无所谓。理解需求、拆分任务、编写测试、高质量的代码实现——很少有程序员意识到，我每天的工作是什么，我的基本功如何。

如果一个人意识到了并且开始刻意训练，他就会在这个团队中鹤立鸡群。

这会带来什么效应？别人会看到这个人价值很大。我 2013 年在 ThoughtWorks 带的员工，在我这干了 1 年，去教合作公司号称有多少年经验的程序员怎么做软件，这些老程序员还很服他。

我们之前讨论过一个问题，为什么明明知道有用，但是我们就是很少人会写单元测试？

除了工作环境，我觉得很大原因是现在至少 80％的程序员都在凭本能开发。

基本功不扎实+不写单元测试，两个加起来就是天坑。以为不写测试做得快，最后会陷入效率低的死循环：

1.对需求把握不准，写完 PM 不认；

2.代码有没有坑不知道，3 个月前写的代码一碰就虚；

3.添加新功能就破坏旧功能，测出一堆 bug 加班修，bug 越修越多；

4.以上循环，就会陷进无限返工、低效率的焦油坑。

2001 年我们敏捷开发圈里一个朋友，用测试驱动开发的方法，大家一个礼拜的活他半天就做完，剩下四天半他就在那上网炒股，后来炒股还赚了不少钱。

很多人说没时间搞测试，这是一个很大的误区。

写测试的本质就是在描述，清晰框定需求，本来就该做的事之前不做，用手快来掩盖方法慢。

更大的问题是，像腾讯、阿里、头条、美团、百度，越是大厂越要测试先行，你在小厂不写测试、工作方式不对，就越难跳到一线大厂。

之前还能吃大锅饭，今年 5 月甲骨文裁员开始，腾讯、阿里、百度、京东、今日头条、美团，很多一线大厂都在紧急做敏捷转型，能力行的上，不行的走，试图通过轻量级的开发和适应性的计划方法来应对市场变化。

我是熊节，前 ThoughtWorks 总监咨询师，拥有十八年从业经验，我曾为多个大型企业架构开发软件系统，带队领导了华为、中兴的敏捷开发转型。

我 10 年前曾翻译过《重构》、《最后期限》、《软件工艺》，希望能把敏捷开发引进中国。

我是如何在工作中实践敏捷开发的？

测试驱动开发（TDD）是敏捷开发的核心实践，就像钥匙——拧动 TDD，就拧开了敏捷开发的大门。

TDD 就像脚手架，为代码提供保护网，他的核心在于严格规定开发节奏，一次把需求理清，一次做对、消除返工，不用调试就能获得反馈。

里边有三个关键：

第一步任务分解：测试先行，分离关注点，并用单元测试表达；

第二步单元测试：遵循 Given-When-Then 三段式，符合极限编程原则；

第三步小步快走：此处的坑在于很多人容易一下写多，破坏 TDD 节奏。

唯一的不爽，这是一个找虐的过程，他迫使你稳定小步前进，所以每一步都必须先想好要达到什么效果，每一步都有充分的测试覆盖。

但一旦会用，节省出的时间会远大于编写测试代码而产生的工作量总和。

掌握测试驱动开发，解决三个老大难问题：

第一，准确把握需求，开发出来的功能一定是客户想要的；

第二，保障软件质量，开发出来的代码一定是有自动化测试覆盖的。

第三，通过反复训练提高开发速度与代码准确率。

6 月份我和极客学院合作，训练了 200+位开发者，帮他们掌握 TDD，让自己受益。

他受益的形式可能是别人 5 天的活，他两天干完，就算公司强制 996，他也可以用剩下 3 天学点新东西，为有一天到大厂、为晋升做准备。

第二期《敏捷开发实战营》将在 8 月 8 号上线，我会亲自带队，训练出一支能熟练应用 TDD 的敏捷开发团队，改进工作方式，提高编程基本功。

我想做的事情就是，第一，通过大量反复的线上训练，能让大家看到我们基本功有很大差距。

第二，我会让你们反复、大量训练，练自己不熟悉的内容，并且快速得到反馈，直至能应用到工作。

本文转载自健荐公众号。

原文链接：https://mp.weixin.qq.com/s/_i1DSVLmbgsKLHZNiJjTdw