“怼天怼地”的CTO，又挨骂了

“怼天怼地”的CTO，又挨骂了 | 极客时间

2022 年 3 月 26 日 InfoQ

昨天在朋友圈看到一条视频，大意是那位博主认为 Debug 是一种低效的认知模式。理由是当程序员去 Debug ，说明他并不知道这个代码发生过什么，需要打一个断点，看看问题再继续做，所以得出擅长 Debug 的程序员不是好的程序员的结论。评论区针对这个观点吵了好几屏幕，正反双方都有理有据。

我仔细一看博主，这不是“老熟人”徐昊嘛。他之前就掀起过好几轮技术讨论，比如接受 InfoQ 采访时说“低代码是毒瘤”等等，也难怪好多人都说徐昊“毒舌”、“有强烈个人观点”、“最能引战”的 CTO 。而今天，我想聊一聊我了解到、跟风评不太一样的徐昊。

快人一步

翻开徐昊的履历，Thoughtworks 中国区 CTO、全球技术策略顾问，中国最早一批测试驱动开发的实践者…你会发现，徐昊的职业生涯总是“向前看”的：

2003 年，在很多人尚未认识到程序员的前景时，还没大学毕业的他，已经码了超过十万行代码，开始寻求从编码速度到编码质量的转变；2005 年，Thoughtworks 刚进入中国，他就选择投身其中，几乎做遍了所有技术角色，最终蜕变为颇有影响力的 CTO 。

因此，敏捷开发才刚在国内有点声势的时候，他就坚定地选择了这一方向，此后还成为了 TDD（测试驱动开发）的布道者。

初识敏捷

由于已经码过超十万行代码，开发速度自然不在话下，初入职场的他以为，日后在工作中把代码质量锻炼出来是顺理成章的事。

但经历了客户和产品经理的一次次“毒打”后，他才发现自己有亿点点天真，下面这些场景每天都在他的工作中重复出现：

1、产品经理觉得自己需求定义清楚了，时间紧任务重让你赶紧开发，快到验收阶段了来一句“这跟我想象的不一样啊”，只能返工；

2、祖传代码看都看不懂，还要在此基础上做新功能，每做一点改动赶紧“跑一下”试试，生怕新功能还没做出来呢，旧功能就不能用了；

3、每回项目上线之前都手忙脚乱的，bug 越测越多，每回测出来的还不一样，顺利上线基本靠运气…

这种一靠本能，二靠摸索，三靠运气的开发状态，给他整迷茫了，连功能尚且无法确保正确，又谈何代码质量？

那段时间，刚好赶上轻量化风潮，极限编程等敏捷开发的概念开始在国内生根发芽，测试驱动开发（TDD）、结对编程、代码重构等这些声称有助于确保代码功能正确且结构良好的开发方法深深吸引了徐昊，他当即决定将这一方法引入公司。

死磕 TDD

本以为推行 TDD 会面临很多阻力，好在徐昊得到了当时一位领导的大力支持，对方认为这是一件长期利好的事情，值得时间的投入，所以允许他在一定限度内拖延项目进展，自此 TDD 得以顺利推行。

根据 TDD 的基本原则，他将开发工作分成了红 / 绿 / 重构三步，在红 / 绿阶段，他不关心代码结构，只关注功能的累积。而在重构的过程中，因为测试的存在，能时刻检查功能是否依旧正确，同时将关注点转移到“怎么让代码变得更好”上去。

这种开发方法在团队流通之后，既减少了短期内的无效开发，降低了修正错误的难度，长期来看，又提升了代码的可维护性与可扩展性。无论是开发人员的个人能力，还是开发于业务层面的贡献，都得到了凸显，百利而无一害。自此以后，徐昊的公司就彻底将测试驱动开发作为其主要的工作方式。

于徐昊个人而言，他也坚定了继续“死磕” TDD 的决心。在他开始带团队，推行高效工作法则时，测试驱动开发始终是核心流程。如今，徐昊把他的多年 TDD 实践经验都融合在了这个极客时间刚刚上线的《徐昊·TDD 项目实战开发 70 讲》专栏里，内容包含 68 讲、40 + 小时视频演示， 4 个完整的项目实践。通过它，你完全可以搞定需求难拆分、TDD 难落地的问题。

徐昊已经跟 TDD 打了将近二十年交道，多次帮国内外的大小团队成功解决了 TDD 的落地，所以想解决在 TDD 中的使用问题或对 TDD 感兴趣想多了解，他绝对是首选。