在Codurance，除非有非常有说服力的解释，否则不管使用什么开发语言，都是从测试开始的。

如果直接空降到这样一个环境，四周所有的人都是这么做的，自然不会有太大的阻力。但在绝大多数工作环境中，真正这么做的还是凤毛麟角，那就要好好问问这个问题，为什么需要TDD。

在进行任何讨论前，都要从一个问句出发才能避免空对空的胡天海吹：要解决的是什么问题？

TDD，或者说软件匠艺要解决的是：如何才能让软件可以有长久的生命力，能够应对不断新增的需求，不拖业务的后腿，进而成为业务的推动力。

Agile、DevOps、软件匠艺其实都是为了解决这个问题。而TDD更多的是从技术角度来提供答案。

其中逻辑如此推演：

TDD实践显然还能带来其它好处，比如用测试记录软件功能和基本单元的行为，大多情况下提供更好的代码质量（低耦合，高内聚）。但就我个人的思考来说，以上是最本质的可以追述到要解决的问题的逻辑推导。

那TDD难么？难。一个没有相关经验的团队，需要数月甚至半年的时间才能回归到最初的效率，这个是同事交流中得出的经验数字；因此想要推行势必要自上而下的支持。同时，除非经历过软件维护噩梦的组织，无法理解这种牺牲的必要性。但一旦过了这最初阶段，整个团队的交付速度会有质的提升，而团队成员也不再疲于奔命，整日在修Bug、调试代码，有精力去关注更多的新工作方式与技术，工作生活的平衡也能得到改善。

我先列下为了解决同样诉求的相关的话题：

• TDD

• 重构

• 金字塔式测试

• 持续集成持续部署（CI/CD）

• 单一主线开发（trunk based development)

• 敏捷项目管理，看板，Scrum，精益制造

• 极限编程（结对编程，快速反馈等等）

• 基础设施即代码 (Infrastructure as code) ，不可更改的基础设施（Immutable infrastructure)，容器化

• 随时生产发布待命（production ready anytime），功能开关（feature flag），功能迭代

• QA左移，安全左移，运维左移

• 自治团队

• 软件模块化，微服务化

所有的这些都构成了一个闭环，都是为了解决如何快速满足业务需求这一终极命题；同时不断也有新的方法去应对新挑战，补足现有的不足。

推荐阅读：

凤凰项目：这是一本讲述一位运维经理的偶遇宗师、传授绝学、临危受命，力挽狂澜的个人英雄主义玄幻修真小说。我的这个介绍是为了避免读者真的拿小说去生搬硬套，但是这的确是我见过最容易读进去的讲述现代IT运维乃至IT项目方法的书籍。其中涵盖了一些重要的精益制造、敏捷项目管理的知识；在通勤地铁上很容易就能看完。

最重要的是，它为困顿于现实泥沼的从业者漏出了一点希望的光亮。不愿意改变是人类的本能，唯有看到了可能性，才有动力去尝试一个短期非最优的方向。