徐昊 · TDD 项目实战 70 讲
徐昊
Thoughtworks 中国区 CTO
18159 人已学习
新⼈⾸单¥98
登录后,你可以任选4讲全文学习
课程目录
已完结/共 88 讲
实战项目二|RESTful开发框架:依赖注入容器 (24讲)
实战项目三|RESTful Web Services (44讲)
徐昊 · TDD 项目实战 70 讲
15
15
1.0x
00:00/20:05
登录|注册

课前必读02|程序员究竟是搞技术的,还是做工程的?

讲述:李辰洋大小:18.34M时长:20:05
本文由编辑整理自徐昊老师在极客时间会员日直播中的演讲《程序员究竟是搞技术的,还是做工程的?》
在我们软件行业里,很多人非常关注自己个人的技术水平:Java 语言出了新版本,我不会;Java 里有个 Kotlin,我不会用;JavaScript 上新框架的版本更新很快,我跟不上;等等。
它们的出现经常会给我们带来一些焦虑。面对这些新技术,要怎么办?学不会就要被淘汰吗?这是大家常有的困惑。而实际上,这种困惑背后的核心问题是:程序员究竟是搞技术的,还是做工程的?这是我们在思考自身职业定位时,要首先去思考和回答的一个问题。
应该知道,技术能力和工程能力是同等重要的,但工程能力却是我们长期忽略和欠缺的。比如我很少听到有人说,自己做软件的工程能力有一点薄弱:
我不知道怎么去做软件的发布和部署;
我不知道怎么在 2-3 人的团队里去 Setup 一个有效的部署流水线;
我不知道怎么在某些环境下完成对软件的测试。
而这,恰恰是我们行业现在所面临的一个重要问题。我们盲目地以为只要技术水平好了,职业发展就能很好。但实际上真正应该提到的,或者说跟职业发展密切相关的,首先是我们的工程能力
当工程水平得到提升后,哪怕技术水平很有限,也能在工程能力的范围下得到很好的发挥。那么到底什么是技术能力,什么又是工程能力呢?

技术能力还是工程能力?

举两个例子,你可以感受一下其中的明显差异。
一个例子是在 LeetCode 上刷题。最近行业里还挺流行干这事儿的,不停地刷题可以让你对数据结构算法更熟悉,也能更熟练地用语言去解决一些小的技术问题。
另一个例子是在项目组里写 CRUD。如果从难度的角度判断,我想你肯定会觉得刷题对于技术的要求更高,而在项目中写 CRUD 的技术含量并不高。
没错,因为它们要求的能力完全不同。你试着回想一下,在 LeetCode 上刷题时,通常会希望自己能在限定时间内尽可能快地、一次性地把代码写完。也就是说,代码写完就完成了,很少需要在此基础上进行二次开发或反复修改。以写为主,而改为辅。
相反,在项目组做 CRUD 时,从技术上看,我们就是在做 CRUD。但与此同时,还需要理解“我为什么要做 CRUD”。这就牵扯到应该如何理解业务上下文和业务逻辑等问题。
随着业务的发展,很少会出现一次性的、代码写完就完成了的情况。因而在项目组做 CRUD 时,写代码可能仅仅占据整个代码生命周期的 5%。剩下的 95%,都是根据需求变化和功能调整,在 CRUD 的基础上再不断迭代。
可以说,从刷题中获得的技术能力,哪怕再强,一旦放到项目组中实际应用,至多能把效率提高 10 倍。假设原来是 5%,提高 10 倍就是 0.5%。即便如此,仍然有 95% 需要在代码的基础上反复修改调整。而这些能力,从刷题中是学不到的。
从而发现,在项目组中做 CRUD 其实更需要我们的工程能力,而在 LeetCode 上刷题,需要的仅仅是技术能力。
再来讲一个比较极端的情况。假设在项目中出现“需求不会做”的情况,此时你面临着两个选择:一是马上向别人求助;二是先自己死磕,实在不行了再找人帮忙。我看弹幕里大多数人选择的是后者。
先说我的结论。如果在我的团队里,我希望你能选择前者。事实上,无论我是 TL 还是团队中的其他人,都希望你能选择前者。选择前者,代表你的技术能力可能较弱,完成不了需求,但却有着非常强的工程能力。
因为工程能力强的第一步,就是不要成为别人的绊脚石。
从工程角度讲,保证项目在低风险的情况下进行,是一个极高的能力优先级。如果存在不能实现的需求,你可以说“这个地方我不会,谁能帮帮我?”这是一个非常好的工程实践。不要因为面子不想让别人知道自己不会,就选择先憋一憋。这样做,只会浪费团队的时间,给团队带来风险。
当然你也可能会说,向别人求助,难道不会浪费别人的时间吗?我要说的是:这不是由你决定的。作为项目的 TL 或者 PM,他会统一全篇的安排,看看是让你继续憋一憋,还是交由其他人来做。如果其他人也不会,可能就需要去请外脑。
从项目风险的角度讲,我们需要通过传递真实的信息来尽可能地降低项目风险,在团队中构建一种信任关系。你说自己能做完就真的能做完,而不会出现“你说自己能做完,其他人觉得你大概率做不完”的情况。
从个人的工程能力讲,构建一种信任关系,不去成为别人的绊脚石,这是程序员最重要的素养。但是在实际工作中,我们很少考虑这样的问题。当然,我们举的是一个极端的例子,目的是帮助你理解,当我们强调技术和工程能力时,能够极端到何种情况。
到这里,我可以将工程能力总结为:在团队协作环境下,长期稳定输出,并持续提高水平的能力。接下来我展开讲解一下。

何为工程能力?

如前所述,工程能力的前提是在团队协作的环境中,意思是这个项目不是你一个人扛了就算。
我们在学校里自学编程时,永远会假设需要我一个人从头干到尾。假设你是项目中最强的 TL,是项目整体的负责人,那么的确需要这样一个人来兜底。但在实际工作中,绝大部分人都是在团队协作的环境下工作,因而就要求我们有“协作”的行为。换句话说,工程能力要求我们怎样才能变成一个更好的 Team  Player
工程能力的第二个要求是长期稳定。这与我们在 LeetCode 上刷题不同。在实际工作中,用多快的速度写完代码其实没那么重要,毕竟未来还需要修改。所以更重要的是,我们要写出更好改、更好读、更容易懂的代码
不需要在短时间内输出一定数量的代码,比如不需要在 1 小时内就写出 700 行代码。更需要的是保持每天两百行的输出水平,就足够好了。长期来看,随着需求的变化,如果能始终保持这样的输出速率,才是我们真正希望程序员能产生的稳定输出的水平。
最后是持续提高水平。协作能力更注重长期持续输出、持续学习与持续提高,它甚至直接决定了我们是否能够具有良好的工程能力。
那么以此为前提,我要强调的是,TDD(Test-Driven Development,测试驱动开发)是目前最具工程效能的开发流程。接下来,就看看 TDD 是怎么帮助我们在团队协作的环境下,完成稳定输出并持续提高的。

最具工程效能?

首先,在团队协作的环境下,做 TDD 时需要先对需求进行任务拆解。换句话说,当任务拆分完成后,实际上就向团队中的所有人表明了我们是怎么理解需求的,将计划怎么去实现它。
这种表明方法并不是“把大象关进冰箱需要三步”这样简单。而是需要把每一步理解到位,把任务切实有效地转化成一个或多个测试。如果能转化成测试,说明真的理解了需求。反之,则说明理解不到位。
实际上,不光我理解了需求,也向其他人证明我的确理解了这个需求,同时还有测试的支撑。这是在团队协作中证明你是一个靠谱员工的基本点。
其次是长期稳定的输出。TDD 之所以能保证长期稳定的输出,是因为需要我们将测试和代码放在一起去写。为什么这么说呢?
估计你听过“测试就是文档”,这句话并不完全对。测试天然不是文档,而只是记录我们实现软件的过程。当实现过程经过加工与整理之后,才能变成真正有效的文档。所以说测试提供了大量技术,比我们在代码中写注释或在文档中写编码设计,更接近实际的实现情况。
而 TDD 这种自动化执行的方法,不仅可以帮助我们验证当时对于需求的理解、产生了什么样的偏差。也很容易帮助我们追溯 Bug 是怎么产生的,以及为什么会产生。在此基础之上,我们的输出才是长期稳定的。这就是我在强调的测试的两个主要目的:发现错误定位错误
要知道,我们的生产效率之所以变得越来越慢,之所以出现不敢改祖传代码的情况,是因为所做的修改一旦出错,就无法定位到底是因为什么出的错。
因而在构造软件的过程中,就需要其中包含一个探测技术,帮助我们定位错误到底在哪里。TDD 中由任务列表产生的测试,既是我们实现软件过程的记录,同时也可以帮助我们发现软件中存在的问题,以及问题产生的定位。
第三个要求是持续提高我们的水平。一方面,在使用 TDD 开发的过程中,我们对需求和架构会有越来越清晰的认识,而需求和架构也会直接反映在任务列表中。事实上,在任务列表中,当产生了越来越清晰的任务,越来越容易转化成测试的任务时,我们的能力本身也就提高了。
另一方面,在写测试的过程中,对于同一类型的任务,实现它的效率不仅可以变得越来越高,而且这个效率还是可以被度量的。比如我之前实现类似的任务时,需要一天的时间。但随着时间的发展,随着技术越来越熟练、认知越来越高,需要的时间就越来越短。因为 TDD 可以帮助我们框定一个大的度量范围。

TDD 的整体工作流程

明确了这些,接下来我们就来进一步探讨 TDD 的工作流程。如下图所示,是我在课程中主要使用的一张图。粗看上去,可能跟你理解的 TDD 有很大的偏差。
首先来看 TDD 的完整工作流程。比如有一组需求,我们需要把需求分解成功能点。从用户可感知的角度,或者是从大的功能块上进行分解时,这些功能点可以直接转化成测试。不过功能点直接转化成测试比较麻烦,那么我就需要在功能点内进行进一步的上下文划分。我们把它叫做功能上下文。
功能上下文的划分怎么来的呢?最简单的方法就是从架构上来,因为架构是表达系统中存在多少种组件,以及组件与组件之间交互的一种方式。比如在 MVC 框架的场景下组件就有三种:Model、View 和 Controller。假如我想实现一个用户登录的功能,从功能点上分,就有两个大的功能点:用户输入正确密码可以登录、用户输入错误密码不让登录。
当我们想实现第一个大的功能点时,就需要做一个用户登录的 View、一个 Controller 和一个代表用户的 Model。那么在输入正确密码可以登录的三个上下文中,不同的组件可以分解成更细小的功能的任务项。
比如说,在 View 菜单上正确登录一个功能时,上面有一项是“我当前的登录界面可以显示用户名密码”的提示,还有第二项是“当用户名输密码时应该被原码覆盖”,等等,会有一些具体的任务项。
很多人在学 TDD 时有一个很大的疑惑:不知道测试从哪儿来。因为当我们看 Kent Beck 的书时,会觉得他天马行空,好像随意写写就出现了很多代码。这背后其实是有很多考量的。
他的考量就是把需求先分解成功能点,由功能点再沿着我们对架构的理解,分解成功能上下文。然后再从上下文分解成具体的任务项,由任务项去写测试。这才是更完整的 TDD 的流程,而测试也是从这儿来的。
同样的问题还有重构。一个很容易跟它混淆的概念是重写,就是拿到代码后,在这上面直接重写一遍。但重构是有一个严格的定义。重构讲的是,我希望它的功能不变,结构变得更好。也就是代码功能本身不变,但是需要让代码结构变得更好。这意味着什么呢?意味着重构调整的是架构
仔细看图,红 / 绿 / 重构循环到底是如何循环起来的呢?简单来说,就是需求分解成功能点,组件和组件之间的关系在功能点映射成功能上下文,并在功能上下文中分解成任务项,任务项再转成测试。然后通过一个或多个测试的失败,直到让测试通过。经过重构,我们就能重新梳理系统中的组件和架构。而重新梳理的组件和架构,会影响功能上下文的再次分解。
换句话讲,当你在 TDD 中去做一次重构,很大可能是当你下一次再用做开发时,对于任务的拆解会发生改变,所以它才能形成一个完整的循环。
分析到这里,就有一个很有意思的发现。TDD 实际上并不是一种编码技术。因为它并不能驱动我们在任务项中把功能都实现出来,它真正驱动的是架构。这正是我们讲的编码架构师,是真正的实干型而非 PPT 型架构师。
那么为什么讲 TDD 是一个工程化的开发过程呢?要知道,架构(组件与组件间的关系)需要在团队间共享。换句话讲,我们可以从中观察一个架构师是不是把工作做好了。
我在做咨询时经常会进行类似的尝试。我会将团队里的开发工程师分别叫到不同的房间,让他们对将要迭代的功能进行任务分解。最后发现,五个人分解出了五种不同的样子。实际上就表明这个团队的架构师没有做任何工作。
架构是整个软件开发过程中最奇怪的一类产出,它本身不发挥任何价值,而只能指导别人的工作。我们只有理解了架构是什么,才能写出正确的架构和正确的代码。当我们说这个架构产生了,如果只存在于纸上,那它不会发挥任何作用。或者说这可能是一个非常容易被破坏的架构愿景。只有架构进入到每个人的头脑中,指导工程师进行具体工作的时候,它才能够发挥作用。
如果所有人根据架构组件拆分出的功能点和功能上下文都是一致的,意味着架构愿景得到了一个比较好的规划,那么剩下的事情才会变得比较简单。
所以在团队中推行 TDD 失败,从来都不是大家不会先写测试,不会进入红 / 绿循环造成的。而是因为没有有效地维护架构愿景,不知道应该按照什么样的方式进行需求分解。
可以说,在做任何软件开发时,理解需求、懂得架构,都是我们开始的前提和出发点。TDD 就是以这种形式告诉我们,必须以一种能被消费、能看得见摸得着的方式向别人展示“我真的懂了需求”。而我真的懂了需求,是因为我可以把需求分解成功能点。我真的懂了架构,是因为我可以在功能点内对架构进行上下文的切分。
如果做到了这些,那么在后续的软件开发中,可能 70% 的问题就都不存在了。TDD 仅仅提供了效率而已。
但是恰恰相反,在我们软件行业,大家非常关注自己个人的技术水平,而不强调工程实践的能力。所以我们行业里普遍缺乏这两种能力:
给我一个需求,我能够恰如其分地分解成对应的功能点;
给我一个架构愿景,我可以把功能点切分成对应的功能上下文。
怎么获得这些能力呢?最简单的办法就是!你可以把 TDD 看成一种训练手段。当你在每一次实践中去强调 TDD,那么最终会变成一个更好的程序员,因为你一直在锤炼程序员工程化水平的最核心的能力。
所以通过 TDD,哪怕我们完全不考虑自动化测试的部分,完全不考虑自动化测试带来的优势,仅仅强调从需求分解和架构愿景上去理解需求,将其变成可验收的任务,我们都能在软件开发效率上得到巨大的飞跃和提高。这就是我为什么讲,TDD 仍然是目前最具有工程效能的开发过程。
不过,TDD 也是目前最难掌握的工程化方法。

最难掌握

对于 TDD,不仅个人学起来困难,在团队中推行也很困难。拿我的学习经历来举例。我从小学四年级就开始参加各种算法竞赛,可以说,我不缺技术水平,也不觉得 TDD 会给我带来什么额外的好处。然而我在 2002 年刚接触 TDD 时,很快就发现它的确能帮助我更有效率地、更有把握地实现工程化的代码。
在自学 TDD 时,我把 Kent Beck 的书看了很多遍。当看到第 30 遍时,突然发现书里有一个非常小的列表,一直在说明下一步要做什么。虽然书中有一个章节都在讲任务列表,但在很长一段时间里,我都没有将任务列表与测试直接关联在一起
后来再回过头思考,才发现原来 TDD 是先产生一个任务列表,而我可以在任务列表上再进一步分解,分解成能够被测试的任务。我花了很长时间来琢磨这件事。同样,这也是很多同学在学习 TDD 时遇到的一个大的困难点。
另外一个挣扎的事情就是,使用 TDD 开发的程序员或多或少都有自己的风格和习惯,而别人的习惯和方法并不完全适用于我们。
TDD 可以被看作是一种编程习惯或者编程方法。就像大家都在跑步,但每个人的摆臂、抬腿动作却不太一样。TDD 也是如此。所以当我去实际使用 TDD 时,对于 Kent Beck 个人的方法,比如三角法,会觉得好像没有什么必要。
于是我强迫自己用 TDD 来编写所有的程序。不光用 TDD 写过应用类的项目,还写过编译器。经过一年多的训练,我才觉得差不多掌握了 TDD。所以它的确是非常难掌握的一种开发方法。
在这近二十年里,我一直尝试通过引入一些实践来降低 TDD 的学习门槛。在课程最后,我也会介绍如果结合了架构、需求分解和测试策略,该怎样利用一些工具帮助我们在团队中更有效地推行 TDD。
如果十年前你问我 TDD 的流程是什么,那给的图肯定跟这个完全不同,当时的图中是没有架构愿景的。所以这个课是我最新尝试的一个总结,希望各位同学能为我提供一些建议,这也是我开设这门课的目的。

小结

当思考职业发展时,我建议不要把眼睛仅仅盯在技术能力上。比如 AI,需要追吗?除非你想立志成为 AI 工程师,否则更需要问的是:AI 何时会工程化?当 AI 工程化后,将会以何种形式与软件工程发生关系?当 AI 进入软件行业,我们做事的方法和风格会发生何种改变?
应该知道,去规划自己的职业生涯时,技术能力和工程能力是同等重要的,但工程能力却是我们长期忽视的和欠缺的。从根本上讲,就是不光要注重自己的技术能力,同时也要注重自己的工程能力。那么 TDD 是我认为目前效能最高的工程化的开发方法,当然,它也是难以掌握的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

TDD(测试驱动开发)在团队协作环境中对程序员的工程能力至关重要。本文深入探讨了TDD的工作流程,强调了需求分解和架构愿景的重要性。虽然TDD是目前最难掌握的工程化方法,但通过练习TDD,程序员可以提高工程化水平,将需求转化为可验收的任务,从而提高软件开发效率。作者分享了自己学习TDD的经历,强调了在团队中推行TDD的困难和个人风格与习惯的影响。文章最后建议,职业发展时不应只关注技术能力,而是同等重要地注重工程能力。作者认为TDD是目前效能最高的工程化开发方法,但也是难以掌握的。因此,程序员应该重视工程实践的能力,通过练习TDD来提升自己的工程化水平。这篇文章为程序员提供了对技术和工程能力的深入思考,对于职业发展具有重要的指导意义。

2022-09-2520人觉得很赞给文章提建议

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《徐昊 · TDD 项目实战 70 讲》
新⼈⾸单¥98
立即购买
unpreview
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • 文经
    置顶
    我觉得光是这一讲加餐就值回票价了。 2023年的第一件重要的事就是跟着课程掌握TDD开发。 1. 工程能力和技术能力同等重要。 2. 工程能力是团队协作、长期稳定、持续提高。 3. TDD为什么是最具工程效能的实践。 4. TDD、重构、架构的关系。 5. TDD的学习、实践方法。
    2023-01-11归属地:广东
    6
  • azurep
    置顶
    很有共鸣。 关于工程能力这块说得太对了,而且举例也是跟我自己的情况基本一样。 我刚进公司的时候也是计算机基础和技术自认为比较出色的,但是真的在做项目ticket的时候就遇到了一样的问题。对于需求的理解不到位,一看之下不太会做也不求前辈们教,之间一拖总是把好多ticket完成的时间拖得很长很长。后面经过组长的细心调教,现在已经好多了。组长说,ask more, work as a team.
    2022-10-06归属地:中国香港
    3
  • webmin
    因为掌握门槛高,所以才值得投入时间去学习。试想如果你几小时就能学会的技能,其他人也同样可以,反复在这样的层次上投入,其实是一种浪费。看过徐老师的编码视频,才能体会到童子功的重要性和高回报。
    2022-09-25归属地:上海
    2
    4
  • Geek_7c0961
    之前没有坚持下来,这次从头再刷.
    2023-02-01归属地:美国
    2
  • 奇小易
    每读一次,对TDD就多一份信心。
    2022-10-19归属地:安徽
    1
  • Y
    打个卡,继续学习下一节
    2022-09-30归属地:广东
    1
  • leesper
    徐老师能不能再专门展开讲讲如何提升工程能力呀
    2022-12-26归属地:贵州
  • coderfone
    讲得太好了
    2022-09-26归属地:上海
收起评论
大纲
固定大纲
技术能力还是工程能力?
何为工程能力?
最具工程效能?
TDD 的整体工作流程
最难掌握
小结
显示
设置
留言
8
收藏
30
沉浸
阅读
分享
手机端
快捷键
回顶部