关于敏捷，Coding Dojo 教会了我什么

在他们的文章 什么是敏捷？ 中，Jen Krieger、Daniel Oh 和 Matt Takane 讨论了我们在红帽公司认为的 敏捷宣言 中最重要的一句话

“通过实践和帮助他人，我们正在发现开发软件的更好方法。”

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

当然，我们经常将“敏捷”与特定的实践联系起来。 让我们以在 Coding Dojo 活动期间一起使用的两种敏捷实践为例。 Coding Dojo 是发现更好的开发方式的好方法……我就说到这里； 你现在已经知道这句话的其余部分了。 Coding Dojo 是通过在安全和受控的环境中与他人一起练习来提高某件事水平的好方法。 我那天发现的实践是测试驱动开发和结对编程

• 测试驱动开发，或 TDD，是一个过程，其中开发人员首先为一个函数编写一个自动化测试，然后编写使测试通过的代码。

• 结对编程是指两个程序员一起使用一台计算机工作。

Coding Dojo 体验

想象一下自己身处一个房间，里面有 20 位程序员、一台笔记本电脑和一个大屏幕。 电脑旁边有两张椅子，供第一对程序员使用，还有足够的座位供其他程序员对在轮到他们使用键盘之前进行观察。

我们那天使用的 kata 是保龄球游戏。正如 Coding Dojo 网站 上解释的那样，保龄球游戏的目的是“创建一个程序，该程序在给定美式十瓶保龄球单线有效滚球序列的情况下，生成该局比赛的总分。”

每对程序员都有五分钟的时间限制，以尽可能小的步骤使用 TDD 来推进挑战的解决。在时间限制结束时，另一对将接替。

第一位程序员首先编写第一个测试。 由于还没有代码，测试失败并显示红色（测试工具将绿色与通过的测试相关联，将红色与失败的测试相关联）。 第二位程序员编写尽可能少的代码以使测试通过并显示绿色，然后他或她改进测试。 测试变回红色，我们切换回第一位程序员，然后他编写尽可能少的代码以使测试通过。 依此类推。 重构是沿途完成的。

两位程序员之间的互动是我们都喜欢看到的魔力。 这是因为贡献者不是提交补丁并希望得到快速审查； 他们正在实时审查。 而且由于他们以小步前进，解释他们在做什么，所以每个人都很容易保持联系，无论您是在观众席上还是这对程序员中的第二位。

首先编写测试迫使人们尽早理解需要什么。 专注于尽可能少的代码以使测试通过也有助于保持设计尽可能简单。 沿途进行的重构确保我们只保留我们需要的代码。

以下是 Coding Dojo 体验与典型开发过程之间的主要区别

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

• 测试在开发之前而不是在代码开发之后完成

• 代码审查是实时与搭档一起完成的，而不是等待另一位开发人员审查和合并

查看大量的代码会使其更难以理解。 该过程不仅速度较慢，而且导致程序员和审查者之间的互动效果较差。

为什么我们将结对编程和 TDD 视为敏捷实践？ 因为它们旨在促进团队各个成员之间强大的互动。 这些互动有助于他们在他们产生的代码中表达他们的最佳水平。

这使我们想到了 敏捷宣言 的第二句话

“通过这项工作，我们开始重视：个体和互动胜过流程和工具。”

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

因此，下次当您参与有关工具或流程的对话时，请问自己（和他人）：我们引入的工具或流程是否会促进个人和互动的发展？

对这个问题回答“是”表明您走的是敏捷之路。