先打个招呼，我要介绍一个老朋友，熊节，在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

创作场景

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