针对单个开发人员的极限编程

Question

在过去的两周里，我一直在使用一些基本的极限编程概念，为了一个小规模的、盈利的、多人游戏、街机游戏。我花了一周时间开发用户故事并确定创建发布计划的需求。我还花了一周时间编写代码，并应用了我提出的第一个迭代计划。对于单个开发人员，我已经确定了一些明显有用的概念。

• 连续积分
• 永远不要过早添加功能
• 测试驱动开发
• 选择系统隐喻
• 使用单个集成点
• 测试所有的错误
• 不断重构
• 设定可持续的步伐
• 简单性
• 频繁发布

我很好奇，我是否遗漏了任何特别适合于使用单个开发人员项目的东西？

而且，考虑到简单性和测试驱动开发的思想，使用已建立的、功能丰富的、现成的平台更好吗？

或者，在可行的情况下，我应该从头到尾地工作，以避免遇到规则所带来的问题，比如不断重构，并且从不过早地添加功能？

Answer 1

最终，极限编程是一套能提高业务价值的实践和方法。我发现的最好的例子是来自http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart

所有蓝色的东西都是XP核心的一部分。

它的某些部分位于它的外部，帮助启用蓝色区域内的东西，并且是整个XP的一部分，但对它来说并不重要。请注意，我本人并不是XP的实践者，我读过很多批评XP的人，“几乎”是在XP之后，很多人都说XP不是XP。让我们先把XP教条的那个方面放在一边，看看我们所拥有的。

要意识到，第一件事，也是大多数事情的一件事，就是要有客户对这个过程的承诺。XP的一个关键组成部分是客户的参与。这体现在许多地点，如发布计划，小版本，离地客户评估。如果您想作为一个单独的开发人员在XP上获得成功，您的客户将需要订阅这些内容。如果他们要求的是一个设计，然后是一个开发周期，然后是测试等等，你就不会得到他们的承诺。

XP并不意味着没有计划。其中有几点规划是它的一部分--优先级、用户故事估计、迭代计划和任务定义。尽管您是这方面的开发人员之一，但您需要与客户一起交付这些内容。

代码的集体所有权和对编程等点都涉及多个方面。对编码标准这样的事情做决定要容易得多，但这并不意味着您不必遵循它们。集体代码所有权仍然适用--只是所有权也是下一个开发人员--不要编写为您和您单独编写的代码。请注意，这在某种程度上与通过对编程启用的“代码显示所有意图”相冲突--您没有那个人来检查您是否正在编写可维护的代码，因此代码文档也是至关重要的。

除了这些警告之外，许多XP设计原则仍然适用。例如测试第一设计，持续集成，与客户的会议，重构，YAGNI，尖峰解决方案-这些调用可以单独完成。

要意识到solo XP和常规XP一样需要更多的纪律。XP通常被认为是一个高纪律方法论，因为它要求人们严格遵守它试图体现的最佳实践。当您没有教练或其他人来支持所需的纪律时，可能会陷入与XP有一些相似之处的大量实践中。

相关阅读：

• XP主题的变体 (马丁·福勒)
• 极限编程 (各种at c2)
• 极限编程 (各种at c2)

我想从第一个c2链接中摘取一段引文：

著名的Perl语言专家达米安·康韦( Damian Conway )认为，极端编程实际上是个用词不当。由于它包含了许多优秀的编程实践，而程序员则被教授，但几乎可以肯定地忽略了这些实践，因此他认为它实际上应该被称为“超保守编程”。