我在一个团队中,我试图说服我的队友采用 TDD(因为我已经看到它在我以前的团队中工作,并且设置是相似的)。另外,我个人的信念是,至少在开始时,如果 TDD 和 Pair Programming 一起完成,它确实会有所帮助。这样,两个没有经验的(在 TDD 中)开发人员可以互相帮助,讨论编写什么样的测试并取得良好的进展。
另一方面,我的经理认为,如果我们同时在团队中引入两种新的开发实践,那么很有可能两者都会失败。因此,他希望更加保守并引入任何一个。
我如何说服他这两者都是互补的而不是正交的。还是我错了?
我不确定有更多的人不知道他们在 TDD 中做什么会有所帮助。它会很快下降到你们两个都在谷歌上搜索这个话题,或者你们两个都在争论 TDD 到底是什么 / 不是什么。
我认为最好让团队中的某个人成为特定技术的传播者(有人去阅读 TDD,有人去阅读配对编程),然后让这些人推广和试用这些东西。是的,两者都可以同时发生,但是它们不必在整个项目团队中使用。您可以让一小组团队进行配对编程,然后报告他们的经验。
配对编程在学习新的实践,尤其是 TDD 时是有效的
因此,您可以折衷方案。以敏捷的方式增量执行此操作。首先进行配对编程。两者中比较容易。配对编程后的所有实践将变得更容易学习,并且将更快,更一致地被团队采用。配对编程是应该采用的第一种(如果不是第一种)工程实践之一。确保它有效地完成。以下是如何进行配对编程的描述。
配对编程是开发团队在开发软件时可以使用的最有效的实践之一。配对发生在两个开发人员使用一台计算机和键盘积极开发故事卡的情况下。经理们担心使用配对编程会使他们的编程成本加倍。乍一看,可以理解为什么他们可能会认为-毕竟-要求两个开发人员在同一任务上一起工作。但是,实际上,使用这种开发技术的敏捷团队发现,与最初的开发成本相比,减少了 15 %。
虽然让程序员配对并一起工作可以提高生产力似乎是违反直觉的,但这种技术真正起作用的原因有很多(想想那句老话,“两个头比一个好”)。
提高质量-配对鼓励代码。键入许多错误会被发现。配对编程意味着由两个致力于代码质量并始终共同努力识别和修复错误的人进行连续的代码。犹他大学进行的一项研究发现,对于成对编写的代码,代码中发现的最终缺陷数量平均减少了 15 %。
花费更少的时间“卡住”-编程很困难。开发人员通常很难找到解决方案,并且花费的时间比他们应该“卡住”的时间更多。有一个合作伙伴可以集思广益,并同意在必要时寻求帮助,从而减少了试图找到解决方案所花费的非生产性时间。
花在分心上的时间更少--当开发人员与合作伙伴一起工作时,他或她不太可能花时间在个人电话或网上冲浪,或电子邮件假期上。
两种观点适用于问题-不同的经验水平,不同的问题解决风格,不同的辅助技能都会增加更快地解决问题的机会。犹他大学进行的研究还确定了成对编写的软件的更好的总体设计和更短的代码长度。
减少对未知事物的恐惧-与单独工作相比,与另一位开发人员配对时,解决问题或尝试掌握新技术更容易。随着时间的流逝,他们也对整个应用程序有了更好的了解。最终,由于配对,该项目最终导致多人了解系统的每个部分。
不太可能在范围内构建-通常开发人员愿意添加需求中未解决的功能。当使用一对时,第二个开发人员更有可能让他 / 她的合作伙伴继续工作。
改进的团队动态-由于采用了配对方法,人们学会了一起工作。他们更频繁地交谈并体验更好的信息流。结果,团队动态得到了改善。实际上,我们发现,最好的团队建设经验是共同生产您的客户感到兴奋的软件。每个人都喜欢成为成功团队的一部分。
消除知识孤岛-领域知识,代码或实践的知识通过团队和开发人员在轮换的基础上迅速传播。
一旦团队对配对感到满意,然后进行 TDD。步行如下:
测试驱动开发(TDD)是一种软件开发工程实践,由短暂的开发组成,首先编写一个涵盖所需改进或新功能的新测试用例,然后实施通过测试所需的生产代码,最后重构软件以适应变化。实际开发之前的测试可用性确保了任何更改后的快速反馈。从业者强调,测试驱动开发是设计软件的一种方法,而不是仅仅鼓励测试驱动的实践。
测试驱动的开发要求在代码本身的每个方面之前编写一个定义代码需求的自动化单元测试。这些测试包含 true 或 false 的断言。随着代码的发展和重构,运行测试可以快速确认正确的行为。基于 xUnit 概念的测试框架提供了一种创建和运行自动化测试用例集的机制。测试驱动的开发周期:以下顺序是基于《测试驱动的开发实例》一书的。
编写测试。在测试驱动的开发中,每个新的故事卡都从编写测试开始。此测试将失败,因为它是在实现功能之前编写的。为了编写测试,开发人员必须清楚地了解功能的规范和要求。这可以通过带有接受标准的 Story Cards 来指定何时满足要求。这也可能意味着在编写代码之前,编写代码是重要的,但在编写代码之前,开发人员的重点是编写代码。
运行所有测试,并查看新测试是否失败。这将验证测试工具是否正常工作,并且新测试不会在不需要任何新代码的情况下错误地通过。新测试也应该由于预期的原因而失败。此步骤测试测试本身是否定的:它排除了新测试始终通过的可能性,因此毫无价值。
编写一些代码。下一步是编写一些将导致测试通过的代码。在此阶段编写的新代码将不完美,例如,可能以不优雅的方式通过测试。这是可以接受的,因为以后的步骤将对其进行改进和磨练。重要的是,编写的代码仅设计为通过测试;在任何阶段都不应和“允许”其他(因此未经测试的)功能。
运行自动测试并看到它们成功。如果所有测试用例现在都通过了,程序员可以确信代码满足所有测试要求。这是开始循环的最后一步的一个很好的点。
重构代码。现在可以根据需要清理代码。通过重新运行测试用例,开发人员可以确信重构不会损坏任何现有功能。删除重复的概念是任何软件设计的重要方面。但是,在这种情况下,它也适用于删除测试代码和生产代码之间的任何重复-例如,在两个代码中重复的幻数或字符串,以便使测试在步骤 3 中通过。
重复
从另一个新的测试开始,然后重复该循环以推进功能。步骤的大小可以与开发人员喜欢的一样小,或者如果他 / 她更有信心,则可以变得更大。如果为满足测试而编写的代码不能很快完成,则步长可能太大,也许应该使用较小的可测试步骤。当使用外部库时,重要的是不要使程序本身的增量很小,以至于不能有效地完成测试,除非
开发风格使用测试驱动的开发有很多方面,例如,在“保持简单,愚蠢”(KISS)和“您不需要它”(YAGNI)的原则下,通过测试驱动的开发将不断提高开发失败的信心,从而使设计比其他方法通常更干净,更清晰。测试驱动的开发要求程序员首先使测试用例失败,并可以捕获。”
建议他们阅读以下有关 TDD 的书籍:
Michael Feather's Working Effectively with Legacy CodeKent Beck's classic Test-Driven Development-By Example
Gerard Meszaros' xUnit Test Patterns-Refactoring Test Code
Test-Driven Development in Microsoft.NET
或配对编程中的这些网站:
Pair Programming (Wikipedia)Corey Haines
Pair Programming Illuminated
你完全正确,结对编程在学习新东西时会有很大帮助。我同意你的观点,你应该努力做这两件事。
也许是为您的经理重复布局的最佳方法。并不是建议您要求同时引入这两个新事物。相反,建议您认为开始实施 TDD 的最有效方法是,在仍要完成工作的同时,只需要两名开发人员作为“TDD 调查团队”,并让他们一起工作以设置适当的工具,学习技术,测试它们,并找出您需要做什么才能将它们应用到您的环境中。
本站系公益性非盈利分享网址,本文来自用户投稿,不代表码文网立场,如若转载,请注明出处
评论列表(85条)