5

我在一个团队中，我试图说服我的队友采用 TDD（正如我在以前的团队中看到的那样，并且设置相似）。另外，我个人的看法是，至少在开始时，如果同时完成 TDD 和结对编程，它确实很有帮助。这样，两个没有经验的（在 TDD 中）开发人员可以互相帮助，讨论编写什么样的测试并取得良好的进展。

另一方面，我的经理认为，如果我们同时在团队中引入两种新的开发实践，很有可能两者都会失败。所以，他想保守一点，介绍任何一个。

我如何说服他这两者是互补的而不是正交的。还是我错了？

4

10 回答 10

13

我不确定让更多不知道他们在 TDD 中做什么的人会有所帮助。它会很快降临到你们俩用谷歌搜索这个主题，或者你们俩都在争论 TDD 到底是什么/不是什么。

我认为你最好让团队中的某个人成为给定技术的传播者（有人去阅读 TDD，有人去阅读结对编程），然后让这些人推广和试用这些东西。是的，两者可以同时发生，但它们不必在整个项目团队中使用。您可以让您的团队中的一小部分人进行结对编程，然后报告他们的经验。

于 2009-05-19T13:17:24.477 回答
9

结对编程在学习新实践时非常有效，尤其是 TDD

因此，您可以通过妥协来兼顾两者。以敏捷的方式逐步执行此操作。首先进行结对编程。这是两者中较容易的。结对编程之后的所有实践都将变得更容易学习，并且将更快地被团队采用，并且具有更高的一致性。结对编程是第一个（如果不是第一个）应该采用的工程实践之一。确保它有效地完成。下面是如何进行结对编程的描述。

结对编程是开发团队在开发软件时可以使用的最有效的实践之一。配对发生在两个开发人员使用单个计算机和键盘积极开发故事卡的情况下。管理人员担心使用配对编程会使他们的编程成本翻倍。乍一看，他们为什么会认为——毕竟——要求两个开发人员一起完成同一个任务，这是可以理解的。然而，在实践中，使用这种开发技术的敏捷团队发现初始开发成本的小幅增加（根据犹他大学的一项研究显示为 15%）被缺陷的减少、更短且更便宜的测试所抵消。周期并减少对生产支持的需求。

虽然让程序员结伴工作可以提高生产力似乎有悖常理，但这种技术确实有效的原因有很多（想想那句老话，“两个脑袋总比一个脑袋好。”）原因如下：

  • 提高质量——配对鼓励代码审查。许多错误在输入时就会被发现。结对编程意味着由两个致力于代码质量的人进行持续的代码审查，并始终共同努力识别和修复错误。犹他大学进行的一项研究发现，对于成对编写的代码，在代码中发现的最终缺陷数量平均减少了 15%。
  • 更少的“卡住”时间——编程很难。开发人员通常很难找到解决方案，花费的时间超出了他们应该“卡住”的程度。与合作伙伴一起集思广益，并同意在必要时寻求帮助，可以减少在试图找到解决方案时花费的非生产性时间。
  • 花在分心上的时间更少——开发人员在与合作伙伴一起工作时，不太可能花时间在打私人电话、上网或电子邮件假期上。
  • 解决问题有两种视角——不同的经验水平、不同的解决问题的方式、不同的辅助技能都会增加更快解决问题的机会。犹他大学所做的研究还确定了成对编写的软件更好的整体设计和更短的代码长度。
  • 减少对未知的恐惧——与其他开发人员合作时，解决问题或尝试掌握新技术比单独工作时更容易。随着时间的推移，他们还可以更好地了解整个应用程序。最后，由于结对，该项目以多人了解系统的每个部分而告终。
  • 不太可能在范围内构建——开发人员通常愿意添加需求中未解决的功能。与一对开发人员一起工作时，第二个开发人员更有可能让他/她的合作伙伴完成任务。
  • 改进的团队动力——由于结对的方法，人们学会了一起工作。他们更频繁地交谈并体验到更好的信息流。结果，团队动力得到改善。事实上，我们发现最好的团队建设体验就是一起合作开发让客户感到兴奋的软件。每个人都喜欢成为成功团队的一员。
  • 消除知识孤岛——领域知识、代码知识或实践知识通过团队和开发人员轮流配对迅速传播。

一旦团队对配对感到满意，然后再进行 TDD。说明如下：

测试驱动开发 (TDD) 是一种软件开发工程实践，由短时间的开发组成，首先编写涵盖所需改进或新功能的新测试用例，然后实现通过测试所需的生产代码，最后软件被重构以适应变化。在实际开发之前测试的可用性确保了任何更改后的快速反馈。从业者强调测试驱动开发是一种设计软件的方法，而不仅仅是一种测试方法。测试驱动开发是一种强大的实践，是减少生命周期后期发现的缺陷的主要贡献者。强烈鼓励新团队与经验丰富的 TDD 从业者配对或以其他方式接受 TDD 指导。e

测试驱动开发要求在代码本身的每个方面之前编写一个自动化的单元测试，定义代码的需求。这些测试包含真或假的断言。随着代码的发展和重构，运行测试可以快速确认正确的行为。基于 xUnit 概念的测试框架提供了一种用于创建和运行自动化测试用例集的机制。测试驱动开发周期：以下序列基于示例测试驱动开发一书，许多人认为这本书是现代形式的概念的规范源文本。

  1. 写一个测试。在测试驱动开发中，每张新的故事卡都从编写测试开始。此测试将失败，因为它是在功能实现之前编写的。为了编写测试，开发人员必须清楚地了解特性的规范和要求。这可以通过带有验收标准的故事卡来完成，以指定何时满足要求。这也可能意味着现有测试的不变或修改。这是测试驱动开发与在编写代码后编写单元测试的区别特征：它使开发人员在编写代码之前专注于需求，这是一个微妙但重要的区别。
  2. 运行所有测试，看看新的测试是否失败。这可以验证测试工具是否正常工作，并且新测试不会在不需要任何新代码的情况下错误地通过。由于预期的原因，新测试也应该失败。这一步测试测试本身是否定的：它排除了新测试总是通过的可能性，因此一文不值。
  3. 写一些代码。下一步是编写一些代码以使测试通过。在这个阶段编写的新代码不会是完美的，例如，可能会以一种不优雅的方式通过测试。这是可以接受的，因为后面的步骤会改进和磨练它。编写的代码只为通过测试而设计，这一点很重要；在任何阶段都不应预测和“允许”进一步的（因此未经测试的）功能。
  4. 运行自动化测试并看到它们成功。如果所有测试用例现在都通过了，程序员可以确信代码满足所有测试的要求。这是开始循环最后一步的好点。
  5. 重构代码。现在可以根据需要清理代码。通过重新运行测试用例，开发人员可以确信重构不会破坏任何现有功能。删除重复的概念是任何软件设计的一个重要方面。然而，在这种情况下，它也适用于删除测试代码和生产代码之间的任何重复项——例如在两者中重复的幻数或字符串，以使测试在步骤 3 中通过。

重复

从另一个新测试开始，然后重复循环以推进功能。步骤的大小可以像开发人员喜欢的那样小，或者如果她/他感觉更自信，可以变大。如果为满足测试而编写的代码不能很快完成，那么步长可能太大了，也许应该使用较小的可测试步长。使用外部库时，重要的是不要进行小到仅仅有效地测试库本身的增量，除非有理由相信该库有错误或功能不够完整，无法满足所有需求正在编写的主程序。

开发风格 使用测试驱动开发有很多方面，例如“保持简单，愚蠢”（KISS）和“你不需要它”（YAGNI）的原则。通过只专注于编写通过测试所需的代码，设计可以比其他方法通常实现的更清晰、更清晰。测试驱动开发要求程序员首先使测试用例失败。这个想法是为了确保测试真正有效并且可以捕获错误。一旦显示，正常循环将开始。这被创造了“测试驱动的开发口头禅”，称为红色/绿色/重构，其中红色表示失败，绿色表示通过。测试驱动开发不断重复添加失败的测试用例、通过测试用例和重构的步骤。

于 2009-05-22T16:11:57.493 回答
2

你是绝对正确的，结对编程在学习新东西时会有很大帮助。我同意你的观点，你应该努力做到这两点。

或许向你的经理展示它的最佳方式不是建议你要求同时介绍这两个新事物。相反，建议您觉得开始实施 TDD 最有效的方法是，在完成工作的同时，只让两个开发人员作为“TDD 调查小组”，让他们一起工作以设置适当的工具，学习技术，测试它们，并弄清楚你需要做什么才能在你的环境中应用它们。一旦你完成了这项工作，并让两个人有一点经验，然后让他们分开，每个人与另一个开发人员坐下来几天，让另一个开发人员快速掌握新技术。重复直到所有开发人员都学会了 TDD。

于 2009-05-19T13:15:55.680 回答
1

你没有说服力。告诉他你认为两者协同工作的原因，也许提供一些证实这一点的数据，然后让他决定。如果你需要让所有人相信这是一个好主意，我敢打赌没有人会接受它。自然反对。

于 2009-05-19T13:14:59.597 回答
1

就我个人而言，我发现结对编程最适合一个有经验的人和一个没有经验的人。

即，我的目标是在程序员的技能/经验上有所不同，而不是试图匹配熟练的技能。

更有经验的人从解释中得到更多，并被迫构建思想，而没有经验的人有机会反弹想法并获得“最佳实践”。

至于TDD，我是个大粉丝。exp 再次帮助没有经验的人，因为它有助于真正带出测试的重点。即您不想绝对测试所有内容......它增加了焦点。我经常发现人们在编写测试时没有关注他们想要达到的目标。

单元测试是必不可少的 imo ... 毕竟，有些员工不会在 2 年内出现。如果没有任何东西可以验证它的功能，你怎么能改变现有的代码呢？

于 2009-05-19T13:58:43.690 回答
0

好吧，取决于经理，您可以指出 XP 文献中的一些论点，即这些实践是相互依赖的。例如，如果您没有可靠的单元测试，请不要无情地重构。

我建议您逐步进行，因为配对只是为了解决 TDD，就像针对新难题的任何协作努力一样，而不是“所有产品开发都将成对完成”。

于 2009-05-19T13:17:34.850 回答
0

虽然一种做法不需要另一种做法，但有一种“偷偷摸摸”的方式一次介绍两者。

从使用可用的 xUnit 框架之一实现 TDD 的目标开始。找一个兼容的同事，询问他们是否愿意每天花一个小时和你一起工作。“肖恩，我正在尝试这个新工具，你能帮我确保我做得对吗？” 效果很好。

和肖恩待了几天后，再和苏珊一起重复……

于 2009-05-19T13:21:28.117 回答
0

无论如何都要这样做。如果经理发现您结对，请说出“代码审查”这个神奇的词
假设：显然，这对结对者应该有足够的纪律/专注，并在会议结束时产生工作代码

于 2009-05-19T13:25:48.733 回答
0

Write some tests that bring attention to existing bugs in the code base - then show them to your boss, I think he might suddenly agree TDD is a good idea!

于 2018-04-11T03:10:49.810 回答