编程道场

在他们的文章中， ，Jen Krieger，Daniel Oh和Matt Takane讨论了Red Hat认为的《 最重要的一句话：

“我们正在探索通过开发软件并帮助他人开发软件的更好方法。”

我喜欢这句话，因为它有助于理解为什么我们可以在软件开发之外应用“敏捷”。 我们可以用“烹饪”之类的句子代替“开发软件”，这仍然使我们对从事“敏捷烹饪”的人们的心态有了一个很好的了解。

事件。 编码Dojo是发现更好的开发方式的好方法。 您现在知道句子的其余部分。 编码Dojo是通过在安全可控的环境中与他人一起练习来改善某些方面的一种好方法。 我那天发现的实践是 测试驱动的开发和结 对编程 ：

• 测试驱动的开发 （TDD）是一个过程，在该过程中，开发人员首先为功能编写自动测试，然后编写使测试通过的代码。

• 配对编程是指两个编码器使用一台计算机一起工作。

编码道场体验

想象自己在一间有20个编码器，一台笔记本电脑和一个大屏幕的房间里。 对于第一对程序员来说，计算机附近有两个席位，对于其他程序员对来说，有足够的席位，他们将在转弯键盘之前进行观察。

我们那天使用的kata是保龄球比赛。 如上所述，保龄球游戏的目标是“创建一个程序，该程序在给定美国10针保龄球保龄球一线有效掷骰顺序的情况下得出游戏的总分。”

每对程序员都有一个5分钟的时间来使用TDD并采取尽可能小的步骤来解决挑战。 在时间表结束时，将出现另一对。

第一个编码器通过编写第一个测试开始。 由于尚无代码，因此测试无法变为红色（测试工具将绿色与通过的测试关联，将红色与失败的测试关联）。 第二个编码器编写尽可能少的代码，以使测试通过绿色测试，然后他或她改进测试。 测试返回红色，然后我们切换回第一个程序员，然后程序员编写尽可能少的代码以使测试通过。 等等。 重构是一路完成的。

两位编码员之间的互动是我们所有人都喜欢看到的一种魔术。 这是因为贡献者没有提交补丁，希望可以进行快速审查。 他们有实时的审查。 而且由于他们以小步伐前进，解释了他们在做什么，因此无论您是在听众中还是在对中的第二个编码器上，每个人都很容易保持联系。

首先编写测试将使您对所需内容早日了解。 专注于尽可能少的代码以使测试通过，也有助于使设计尽可能简单。 一路进行重构可确保我们仅保留所需的代码。

以下是Coding Dojo经验和典型开发过程之间的主要区别：

• 开发人员成对工作，而不是单独工作以编写功能并修复错误

• 在开发之前而不是在代码开发之后进行测试

• 使用一对，实时进行代码审查，而不必等待其他开发人员审查和合并

查看大量代码会使它更难理解。 该过程不仅较慢，而且导致编码者和审阅者之间的有益交互较少。

我们为什么要考虑结对编程和TDD敏捷实践？ 因为它们旨在促进团队中各个成员之间的强大互动。 这些交互帮助他们在所生成的代码中表达自己的最佳表现。

这使我们进入了《 的第二句话：

“通过这项工作，我们获得了价值：流程和工具上的个人和互动。”

您当然可以拥有流程和工具。 但是那些过程和工具应该促进个人及其互动的表达。 后者比前者更具价值。

因此，下次您进行有关工具或过程的对话时，请问自己（和其他人）：我们是否正在引入一种可以促进个人和互动的工具或过程？

对这个问题回答“是”将向您展示敏捷方法。

接下来要读什么

翻译自:

编程道场