写点什么

虚拟座谈会:TDD 有多美?

  • 2011-02-23
  • 本文字数:6622 字

    阅读完需:约 22 分钟

【编者按】最近酷壳的一篇有关TDD 的文章引起了广泛关注,对于TDD 一些人有自己不同的见解,为此InfoQ 中文站特地邀请了InfoQ 内外的敏捷专家特别是有丰富TDD 实践经验的人,就TDD 为InfoQ 的读者分享他们自己的经验和体会。

InfoQ:请介绍你自己,以及 TDD 的实践经验。

熊节:ThoughtWorks 中国公司首席咨询师,曾参与《重构:改善既有代码的设计(中文版)》、《J2EE 核心模式(原书第 2 版)》、《Contributing to Eclipse 中文版》等图书的翻译。目前正在从事 Ruby on Rails 的项目,并致力于敏捷方法与思想的推广。熊节从 2003 年开始实践 TDD,从此以后使用此方法编写每一段交付使用的代码,直至今天。

鲍央舟:OutSofting 的敏捷咨询师。在从事咨询工作之前,从事软件工程师的工作。接触、使用过一些 TDD 的实践,但是由于大环境的原因,没有深入使用。在从事咨询工作之后,和一些有经验的 TDD 高手做过 Pair,也对 TDD 有了更深入的理解。

滕振宇:独立敏捷教练,InfoQ 敏捷社区编辑,国内唯一的认证 Scrum 教练 (Certified Scrum Coach)。从 2005 年接触到持续集成并开始实践,接下来开始接触并实践 TDD 以及 Scrum 等敏捷方法。

田乐:无限讯奇高级开发工程师,工作有 7 年,是一个前端后端都做的程序员。从 07 年开始使用 TDD。

段念:Google 中国高级测试经理,10 来年软件开发与测试经验,主要工作方向在软件测试。在某些项目中实践过 TDD,ATDD,在推动开发工程师的开发测试过程中对 TDD 有一些思考。

InfoQ:TDD 跟 Test 是什么关系呢?TDD 的 T 就是 Unit Test 吗?

熊节:可以是。也可以不是。关键在于,是不是都无所谓。我前两个星期就在干一个用 Cucumber+Selenium 直接写 spec 来驱动开发的项目,照样干得很清爽。 关键在于,TDD 的 T,是什么测试都无所谓。它就是设计。或者如果要把词汇定义得再准确点的话,你脑袋里的那个东西是“设计”,你在写生产代码之前写下来的那段东西是“设计的展现形式”,只不过它恰好是一个可以执行的 JUnit 或者 whatever 测试用例。

那么接下来应该问的是:什么是合理的设计的展现形式? 答案是,它应该是无二义的、可执行的设计的验收条件。因此你不仅可以说“我有一个设计”,并且可以说“我把设计记录下来了”,并且可以说“我写的代码是符合设计的”。而这后面两件事(尤其是最后一件事),我没有看到其他任何一种设计方法可以有效地保障。

所以“关注测试而不是设计”这种说法,它不是对不对的问题,它是可笑的。当你说一种设计方法不关注设计,你到底是在说什么呢?或者你不认为它是一种设计方法?那么当你说你使用了一种设计方法但你并不认为它是一种设计方法,你到底是在说什么呢?

鲍央舟:TDD 更是一种工作方式,编码观念,而 Test 是这种观念中的一部分实践。具体说来,TDD 的观念是先明确下一步要做的一小样东西,然后恰到好处的实现要做的东西,最后审核所做的质量,以此循环。Test 是明确下一步东西后的产出,对实现的正确引导,也是审核将来代码质量的一个工具。按术语来说,TDD 的 T 确实是 unit test。Unit test 是跟代码质量,编码思路密切相关的。也有 ATDD,BDD 之类的,与代码的外部功能相关。

:TDD 跟测试的关系: - 测试是 TDD 的必然结果。如果团队一直在实践 TDD,所有的代码都会有相应的测试,所有的测试其实就是整个系统的脚手架。

  • TDD 方式的开发是从写测试开始的。
  • 使用 TDD 时,功能开发总是实现沟通结束条件,也就是在何种情况下,可以认为功能完成,这个结束条件是以测试体现的。
  • 实践 TDD 时,写代码只有两种目的:1. 让一个失败的测试通过。2. 在不添加新功能(也就是不需要添加新的测试)的前提下,让代码、结构或者测试更加清晰、整洁、易懂。

狭义上 TDD 的测试指的是单元测试,但是随着敏捷开发方法的发展,TDD 又逐渐延伸发展出了 ATDD(Acceptance Test Driven Development)和 BDD(Behavior Driven Development)等。每种方法关注于不同的问题。在这里我用 Google 的敏捷和 TDD 教练 Misko Hevery 基于 Mike Cohn 的测试金字塔延伸出来的金字塔来说明敏捷开发中各种测试的关系。

  • 基于 UI 的测试,这一部分不可能做测试驱动,因为 UI 总是在最后完成的,不可能提前。
  • 功能测试,这一部分是关注于系统的业务逻辑,通常是用 ATDD 和 BDD,是集成测试。这一部分保证系统做正确的事情 (Do Right Things)。在迭带初期阶段,讨论用户故事的结束条件,用例子来体现,这些例子就形成了自动化的功能测试。
  • 单元测试,这一部分保证系统的每个单元(类和方法级别)的逻辑正确,更关注于正确地做事情 (Do Things Right)。

但是这些不同的测试之间也没有明确的界限,每个人有不同的理解或者实现方式,很多人也会先从简单的单元测试着手,然后逐步把单元测试重构组合成集成测试用例。

田乐:TDD 是从 Test 开始的,驱动开发过程的动力是失败的测试,Test 是驱动设计的工具。TDD 肯定需要有 Test,不过 Test 大部分的时候都不是为了 TDD 而写的。TDD 的 Test 不是 Unit Test,它可以是 Acceptance test(ATDD)、Functional test 等等。一般来说 TDD 可以穿透测试的几个水平分类。 Test Category 理论我记得以前 InfoQ 有写。单元测试对应的是集成测试。单元测试一般指对函数级别或者 OO 环境中的类级别的测试,特点就是没有外部依赖。集成测试是测试组件之间协作的测试,一般都会验证和用户需求有关的一些行为是否可以完成,也可以验证设计的组件协作是否可以完成。大型的系统还会把最顶端的集成测试叫做系统测试。AT 或者 UAT 是从系统的外部行为验证软件的功能是否可以完成,它们在这种分层维度里面应该算系统测试,只是它要求这种系统测试是黑盒的。

功能测试是对应非功能测试的,就是是指验收的场景是否和 Use Case 有关。还有回归测试,它一般是用来验证曾经发现的缺陷的。

TDD 中的测试可以是上面所有分类中的任何一种。

段念:TDD 并不是石头里蹦出来的孙悟空,DBC(Design By Contract)可以看作是 TDD 的前身。在 DBC 的观点里,设计应该以规约(Contract)的形势体现,规约定义了被开发对象的行为。延续这个观点到 TDD,很容易就能理解,TDD 中的 T,在表现形式上是“测试”,但其实,它更应该被理解为“对被实现对象”的行为限定,也就是 DBC 中的规约。“测试”只是用来体现规约的形式。 单元测试通常被定义为“对应用最小组成单位的测试”,它的测试对象通常是函数或是类,在对类的设计和实现应用 TDD 时,为类建立的测试通常与类的单元测试相当类似,因此 TDD 中的 T 往往被误认为是单元测试本身。实际上,这两者还是有显著的区别的。首先,TDD 中的 T 描述的是规约,是设计的一部分;其次,TDD 中的 T 并不明确要求 T 对实现代码的覆盖率;第三,TDD 的 T 的侧重点是“描述被实现对象应该具有的行为”,而不仅仅是“验证该类的行为是否正确”。当然,TDD 中的 T 在形式上是测试,在重构中也可以作为被实现对象的行为验证框架。

单元测试、集成测试、系统测试、用户验收测试是基于传统软件开发过程的划分,在传统软件开发观点中,这几类测试不仅意味这测试对象的不同,同样也以为着不同的测试在开发周期中处于不同的位置。但在敏捷开发中,如果继续使用这几个名词,最多也只能保留它们在测试对象方面的含义。对于 TDD 来说(ATDD 和 BDD 可以认为是 TDD 的变体),在不同的测试类别中都可以应用之,唯一的区别在于 T 面向的对象不同。

InfoQ:你认为实施 TDD 需要怎样的前提条件?TDD 难在哪儿?

熊节:要使用一种设计方法,你就必须(1)会做设计;(2)做设计。它难在有些项目不做设计,有些人不会做设计。

鲍央舟:实施 TDD 的前提是对 TDD 实践背后的观念有所理解,也需要有经验者的指导。TDD 难在习惯和观念的转变。以前的工作方式已经在大脑和肌肉中固定下来,无法短期更改。另外,在短期可能呈现开发速度更慢的现象,需要管理层也对 TDD 以及质量有所理解,才能给予正确的支持。

:前提条件很简单,就是了解这种工作方式(可以通过读书,可以通过跟教练一起结对等),然后去坚持。 TDD 很难:

  • 关键是人的因素,人的个人修养。类似于健身,人人都知道经常锻炼的好处,但是真正没有几个人去坚持,这需要很高的纪律性。
  • 要了解的东西太多,需要不断学习,如果不了解如何做好的设计,怎样去解耦等等,否则 TDD 会做得很痛苦。多数人却比较懒散。
  • 大家往往认为老的系统代码太烂,耦合度太高,无从下手。

田乐:前提条件就是需求明确,知道需求的边界,了解如何可以验收。另一方面 TDD 要经过一些练习。我觉得 TDD 的一个难点就是把它当作一个推动设计的工具,而不是停留在保证质量(如检查边界条件)这个层面。另外,由于 TDD 一般是从最外面的抽象开始的,所以我个人觉得 TDD 最开始的抽象模型选择也是一个难点。

段念:实施 TDD 是对开发者行为的比较大的改变,在我的经历中,遇到的主要难点应该是改变既有的开发工程师的开发习惯吧。TDD 技术本身没有什么特别的要求,任何组织都可以直接应用。

****InfoQ:TDD 之于需求、设计、代码质量是怎样的关系和影响?

鲍央舟:对于需求来说,TDD 更能引导开发人员做出真正符合需求的东西,不会过渡开发。对于设计来说,TDD 的实践能帮你清理思路,但不能教会你做好的设计。对于质量来说,TDD 保证所有的代码都有测试覆盖,肯定能提高质量。

:需求方面根据 2002 年 Standish Group 的报告,我们软件系统中有 65%的功能是客户从来不用或者很少用到的。传统意义上大家认为敏捷开发应该让我们的团队开发得更快,生产率更高,这其实是很大的误解。与提高效率相比,使用 Scrum,TDD 能够帮我们从整个需求中确定真正有用的那 35%,而且往往这 35%的功能往往实现起来并不是那么困难。因为做得少,所以做得更快。

TDD 与设计、代码质量方面,我想引用 Keith Braithwaite 在 XPDay 的分享话题“ Measure for Measure ”。他分析了很多的开源项目,发现有趣的现象,有自动化测试的那些项目,质量要好于没有 TDD 的项目(参见下图,所有有自动化测试的项目斜率 (Slope) 都是 >2 的,想要了解斜率的具体含义,可以去听 Keith 的话题分享)

田乐:TDD 会让你减少无用功,因为它迫使你从需求验收的角度入手,你必须在进入细节之前找到这个需求的边界,找到那些验收条件。TDD 会锻炼自顶向下的的抽象分解能力,这对仅习惯从细节入手的程序员来说很有帮助。TDD 可以提高你的代码的可测试性,它的节奏还可以帮助你做到简单设计。还有大家常说的,TDD 有助于提高代码的内部质量。

段念:ATDD 可以向上直接追朔到需求,使用 ATDD 方式,可以避免功能镀金,这是 TDD 技术带来的一个大的好处。在设计方面,TDD 并不追求在最开始的时候得到一个完备的设计,而是遵循“够用的设计”的原则,保证开发者可以在短时间内得到可用的设计与实现。“够用的设计”是一个在敏捷环境下非常有效的原则,当然,也有些人反对这个原则,认为随意的设计无法随着应用的复杂性增加则很好的适应。在我看来,由于需求本身的不确定性,很难期望在一开始的时候就能给出保证能满足将来需求的设计,既然这样,不如遵循“够用的设计”的原则,通过重构等方式不断修正和优化设计。TDD 对代码质量本身没有明确的关注,但如果开发者自觉地不断应用重构技术消除代码中的 bad smell,在组织级别设计强制的 code review,以及对单元测试覆盖率给出明确要求,则可以在很大程度上让代码质量保持在高水平上。

InfoQ: 你认为实施 TDD 容易犯的错误是什么?TDD 的不足在哪些方面?

熊节:错误?陈皓同学已经向我们展示了。当你使用一把锤子时,你能犯的最大的错误就是尝试用它把钉子撬出来而不是砸进去。 不足?当你不知道该怎么用最理想的方式来描述你的设计,好吧,不管是因为什么原因,你当然只好退而求其次。你尽可以把设计的复杂和设计能力的欠缺归咎于你用的锤子。反正 TDD 又不会说话。不过,当你甚至不能为你的设计写出一个测试,你究竟打算用什么方式向别人讲述这个设计呢?或者也跟着退而求其次,反正我已经有设计了你就别管这个设计是什么反正我做出什么你就用什么吧──没错,很多人一直是这样工作的。

鲍央舟:过度编码!写完测试后,代码不止使新测试通过,还实现了很多别的东西。不足只是真正掌握比较难而已。

:容易犯的错误: - TDD 的名字取得不好,大家往往产生误解,认为只要先写测试,再写代码就是 TDD。在很多号称使用 TDD 的公司,这些测试甚至是测试人员写的(这不就是瀑布里面的 V 模型么?)

  • 不重构,只要让测试用例通过就结束。对于一个 TDD 的实践者来说,他往往花很少的时间去实现功能,让用例通过。他会花绝大部分时间去重构,去让代码变得更加容易理解,设计更加清晰。

不足之处:

  • 太需要实践者的坚持,“上士闻道,勤而行之,中士闻道,若即若离,下士闻道,大笑之,不笑不足以为道。”但是往往只有少数人会真正踏踏实实去实践。有些人三天打鱼两天上网,另外一些人会去嘲笑这种做法。
  • 很难去向公司上层以及项目经理去证明其价值。

田乐:我觉得 TDD 最容易出现的就是节奏问题,由于有的时候 coding 的非常尽兴,就没有遵循红绿红绿小步前进(baby step)的节奏,而是在没有失败的测试的时候就洋洋洒洒写下去。那样的做法其实就不完全是 TDD 了。TDD 的不足是它不是万能的,不应该是强制的。不是所有的任务都需要 TDD,那些临时的可抛弃的代码(如技术可行性试验)不需要 TDD。强制的 TDD 和强制的单元测试一样,因为设计优略不容易量化,TDD 也不能用 TestCase 的数量去量化,没法量化的实践不应该是强制的,否则会流于形式。TDD 无法量化也是它被大规模推广的时候的一个不足。

段念:把 TDD 等同于单元测试,认为 TDD 只是“提前写单元测试”这种想法应该是很多不太了解 TDD 的人容易犯的错误吧。如果把 TDD 放到敏捷开发的大背景下,我倒不觉得 TDD 有什么明显的不足,但如果单独考量 TDD 在企业中的实践,TDD 技术本身不关注代码的质量应该是一个明显的问题。应用 TDD 的企业通常需要采用持续的 Code Review 和 Refactory 方法保证通过 TDD 产生的代码的质量。

InfoQ:一般开发者需要多久能掌握 TDD 呢?请向读者推荐一下 TDD 的学习资料吧。

熊节:到他们掌握该怎么做设计时──which never happens to most people,请参阅《程序员的思维修炼》。 至于学习资料么,问豆瓣都比问我好。这事情也很悖论:能学会的人,读这些文字的价值约等于 0,因为他只需要豆瓣搜索 1 分钟 + 阅读 1 小时──这是他 anyway 会做的事──就能得到同样的信息;读了这些文字觉得很有用的人,有鉴于 Kent Beck 那本书出版已经 7 年了,基本上,他已经没希望了。

鲍央舟:半年!网上一搜可以一大把资料,不过我觉得 TDD 光看是没用的,一定要和有经验的人 pair!

:多久才能掌握 TDD 呢?这不是一个“敏捷”的问题,因为每个人的学习能力,和对学习的投入程度是不一样的,因此学习的“速度”也不一样,因此很难说需要多场时间。在这里我采用敏捷计划与估计的做法,我们先确定一下范围,然后每个读者根据自己的学习速度,自然就可以算出需要多场时间。 做好 TDD 需要了解很多的技巧、工具、原则,我想用 Ron Jeffries 的“敏捷技能的七个支柱”来说明需要掌握的东西。在这七个支柱中

  • 需要掌握“技术卓越”(Technical Excellence)
  • “业务价值”中的“用户故事”及“递增迭带式发布”
  • “自信”中的“持续集成”
  • “产品”中的“易学易用”

所有这些背后都隐含着很多的学习要点,这些要点需要通过读很多书、资料、与专家交流才能掌握。

TDD 的学习资料

书:

  • Kent Beck 的“测试驱动开发”
  • Martin Fowler 的“重构”
  • Bob 大叔的“敏捷软件开发原则、模式、实践”和“代码整洁之道”
  • Michael Feathers 的“修改代码的艺术”
  • Gerard Meszaros 的“XUnit 模式”
  • Roy Osherove 的“The Art of Test Driven Development”
  • Steve Freeman 的“Growing Object Oriented Software Guided by Tests”
  • Eric Evans 的“领域驱动设计”等。

视频

  • 到 Google 去查 Kata
  • James Shore 的“Let’s Play TDD”系列

田乐:不知道多久可以掌握。学习资料的话 Kent Beck 的 TDD 就很好,还有我觉得 TDD 很适合与设计的方法论一起看,如领域模型驱动设计等(《测试驱动的面向对象软件开发》就结合了这两个知识)。

段念:我们组织中有一些用于帮助开发工程师熟悉 TDD 的 program,根据我的了解,一般的开发工程师可以在 1-2 周内掌握 TDD 工作方式,但一般需要更长时间来达到对 TDD 的熟练掌握和灵活应用。

2011-02-23 00:0015601
用户头像

发布了 127 篇内容, 共 40.4 次阅读, 收获喜欢 4 次。

关注

评论

发布
暂无评论
  • BDD 是什么东西?

    当 JUnit 带来的自动化测试框架风潮迅速席卷了整个开发者社区,成了行业的事实标准,就开始有人基于测试框架的模型进行延伸了。各种探索中,最有影响力的就是 BDD。

    2021-09-13

  • 01|TDD 演示(1):任务分解法与整体工作流程

    理解需求,并通过测试构成高效的节奏,是有效实施TDD的前提。

    2022-03-16

  • Jim Shore 提出自动化验收测试得不偿失

    许多备受青睐的敏捷著作都建议你说:捕获用户需求的最佳途径是把例子编写进自动化测试——即“自动化验收测试”。尽管引来诸多质疑,但思想领袖Jim Shore认为也许不该这样。

  • 渐进式敏捷:由下而上的敏捷推行策略

    如果组织高层领导大力推行敏捷那当然是好事,但很多时候敏捷的主要推行者还是技术人员和中层技术型管理者,老板们还在等着看他们实践的成果。在这种情况下,有计划、有技巧地采用渐进式的、由下而上的推行方式,可能就是让敏捷在企业中扎根的第一步。

  • 技术指导实践指南

    在过去的4到5年中,我一直担任软件开发教练,帮助组织改进他们的技术实践。经过几次迭代,我开始专注于XP实践,特别是TDD、结对编程、重构和简单设计。在本文中,我将分享我组织辅导课程的经验,包括主题选择和执行顺序、每个主题的练习和形式。

  • 敏捷咨询工具箱(三)──结对辅导

    在前面的两篇敏捷咨询工具箱中,我分享了如何做<a href="http://www.infoq.com/cn/news/2010/12/qac-agile-tool-box-reading">读书写代码活动</a>和<a href="http://www.infoq.com/cn/news/2010/12/qac-agile-tool-box-oo">OO训练营</a>。认真的做好这两项活动之后,团队的开发设计能力会提升一个台阶。对于有经验和有能力的团队,他们可以直接把这些技术和思想直接应用到项目中。但有一些团队还需要进一步的跟进。那我们如何进一步的跟进,保证大家能把这些技术应用到项目中呢?

  • 虚拟座谈会:代码测试比率、测试驱动开发及行为驱动开发

    过去几个月间,互联网上关于测试先行还是测试居后、代码测试比率或者行为驱动开发(BDD)是否真的是测试驱动开发(TDD)的讨论进行得如火如荼。InfoQ访问了行为驱动开发(BDD)和测试驱动开发(TDD)领域的专家们,请他们就此发表观点。

  • 敏捷是怎样改变测试管理的

    敏捷方法中内建了许多传统的测试管理活动,随着人们对敏捷团队特性,例如自组织、角色的模糊化以及技能的多样性的期望,测试管理的性质也随之改变了。我们必须回答的问题是,在高效的敏捷组织中,测试经理这一角色是否还有存在的必要?这一角色一直以来所从事的这些活动又是如何被剥夺的呢?

  • 怎样在企业里推广 TDD 等技术实践?

    Agile和DevOps的成功的原因之一在于,开发人员改变他们的工作方式,采用了测试驱动开发(Test-Driven Development,TDD)。这种改变不会自然而然地发生,而大多数“常规”的推动改变的方法也并不适用于TDD。在本文中,作者将分享她在这方面的一些成功尝试,以及她在指导开发人员时所使用的“Samman”方法。

  • 自动化的验收测试──是否只是纸上谈兵?

    编写需求并自动生成验收测试,在这方面已经有了零星的成功案例。然而社区中只有很少数的人这样用过。每个迭代开始编写的自动化验收测试真的只是纸上谈兵吗?由于很少有人采用,这种方法是否难以奏效?

  • 第二届功能测试演讨会简报

    做为Agile2008大会的热身,第二届敏捷联盟功能测试演讨会召开了。Jeff Paton主持了多个开放式Session。这次演讨会的主要目的是讨论当前自动化功能测试领域的新颖观点,以及未来的自动化功能测试工具可能是什么样的。

  • 测试计划驱动开发模式 TPDD:一种比 TDD 更友好的开发模式

    TDD并不是一个开发者友好的开发模式,只是一个理想化的开发模式。

  • 高质量代码——书评与采访

    由Stephen Vance所撰写的《高质量代码》(Quality Code)一书涵盖了软件开发生命周期的各个方面,尤其关注于提交高质量的产品。Stephen在本书中谈论了为支持软件技术水准测试所需的一些实践。InfoQ有幸与作者进行了交流,对本书的内容以及测试应用程序代码的最佳实践进行了一番讨论。

  • 07|TDD 中的测试(3):集成测试还是单元测试?

    TDD中的测试并不是行业中所谓的“单元测试”,而是指能提供快速反馈的低成本的研发测试,也是针对不同粒度单元的功能测试。我们要从发现问题和定位问题的角度出发,去理解和思考每一个测试的功效。

    2022-03-22

  • 答疑解惑 | 如何分解一个你不了解的技术任务?

    要做一次技术 Spike,Spike 的作用就在于消除不确定性。你要让项目经理知道,这里要用到一项全团队没有人懂的技术,需要花时间弄清楚。

    2019-02-13

  • 测试专栏特别放送 | 答疑解惑第一期

    特别选在专栏即将结束的节点上,我和编辑一起策划了这个“答疑解惑”系列,从已发布的文章,以及对应的留言中,精选出一些问题,为你解答。

    2018-10-17

  • 迈出单元测试的第一步

    在这篇文章里,Gil Zilberfeld介绍了编写单元测试时符合要求的小技巧,以及在开发周期里进行单元测试的步骤。

  • 开发模型的演化

    当前敏捷是王道,但是未来一定会出现更好的模型。

  • TDD 就是先写测试后写代码吗?

    在最后的扩展篇,我将给你介绍 TDD 和 BDD 两项实践。在你学有余力的情况下,可以挑战一下,让自己再向前走一步。这一讲,我们先来说说 TDD,也就是测试驱动开发(Test Drvien Development)。

    2021-09-10

发现更多内容

JUC中的AQS底层详细超详解

华为云开发者联盟

Java 开发 华为云 企业号十月 PK 榜

【1024】程序员节丨致敬所有技术布道师

MobTech袤博科技

1024程序员节 MobTech袤博科技

前端培训机构包就业靠谱吗?

小谷哥

盘它!基于CANN的辅助驾驶AI实战案例,轻松搞定车辆检测和车距计算!

华为云开发者联盟

人工智能 华为云 辅助驾驶 企业号十月 PK 榜

请求投放个性化广告时,如何征得用户同意?

HMS Core

广告

对象存储只能按文件名搜索,你out了吧

华为云开发者联盟

云计算 存储 华为云 企业号十月 PK 榜

长安链源码分析之交易过程分析(7)

java培训哪家比较靠谱

小谷哥

大数据培训学习就业难吗

小谷哥

软件测试面试真题 | MYSQL中删除语句有哪些?

测试人

sql 软件测试 面试题 测试开发

SpringCloud-05 Hystrix学习笔记

游坦之

10月月更

百度搜索业务交付无人值守实践与探索

百度Geek说

Pytho 企业号十月 PK 榜 智能测试

长安链源码分析之交易过程分析(8)

深度解析9种ScheduledThreadPoolExecutor的构造方法

华为云开发者联盟

高并发 开发 华为云 源代码 企业号十月 PK 榜

腾讯前端常考vue面试题整理

bb_xiaxia1998

Vue

java开发培训机构要怎么谨慎选择

小谷哥

学会这10种定时任务,我有点飘了

小小怪下士

Java 程序员

Checkout.com支付解决方案,助力跨境电商领跑购物季

科技热闻

高可用和负载均衡的三大区别详细讲解-行云管家

行云管家

高可用 高可用集群 ha

阿里云移动测试-远程真机篇

移动研发平台EMAS

性能测试 app测试 移动测试 远程真机

微信小程序wx.getLocation审核不通过的解决方法

源字节1号

前端开发 小程序开发

开源软件供应链攻击激增430%,供应链安全不容小觑丨行业报告解读

SEAL安全

开源 DevOps 行业报告 软件供应链安全

React源码解读之React Fiber

flyzz177

React

软件测试 | 测试开发 | 如何确保API的稳定性与正确性?你只需要这一招

测吧(北京)科技有限公司

测试

vue面试之Composition-API响应式包装对象原理

bb_xiaxia1998

Vue

使用注解 @requires 给 SAP CAP CDS 模型添加权限控制

Jerry Wang

云原生 CAP Cloud SAP 10月月更

web前端开发培训女生学习怎么样

小谷哥

日报周报是“毒瘤”还是“良药”?

优秀

周报 日报

Springboot 一行代码实现文件上传 20个平台!少写代码到极致

程序员小富

Java springboot 文件上传

React源码解读之任务调度

flyzz177

React

SpringCloud-04 Feign学习笔记

游坦之

10月月更

虚拟座谈会:TDD有多美?_Java_张凯峰_InfoQ精选文章