面向单个开发人员的极限编程[关闭]

在过去的两周中，我一直在研究一些基本的极限编程概念，用于小型，营利，多人，街机游戏。我花了一个星期来开发用户故事并确定创建发布计划的要求。我还花了一周的时间编码并应用我想出的第一个迭代计划。我已经确定了一些对于单个开发人员有用的概念。

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

我很好奇我是否缺少特别适合与单个开发人员项目一起工作的任何东西？

同样，鉴于这种简单性和测试驱动开发的思想，使用建立的，功能丰富的，现成的平台更好吗？

还是应该在可行的情况下从头开始工作，以避免遇到规则不断提出的问题，例如不断进行重构并且永远不要尽早添加功能？

最终，极限编程是关于一组可以提高业务价值的实践和方法论。我发现的最好的例子是从http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart

蓝色的所有内容都是XP 核心的一部分。

它的某些部分位于其外部，有助于在蓝色区域内启用某些功能，它们是XP整体的一部分，但对它并不重要。请注意，我个人不是XP的从业者，并且在XP之后，“几乎”我读到很多批评，很多人说这不是XP。让我们将XP教条的这一方面放在一边，看看我们有什么。

要意识到，对客户而言，最重要的事情之一就是对流程做出承诺。XP的关键组成部分是客户的参与。这在发布计划，小版本发布，异地客户评估等许多方面都可以看到。如果您要成为XP的独立开发人员而获得成功，这些客户将需要订阅这些内容。如果他们要求设计，然后是开发阶段，然后是测试等，那么您将没有他们的承诺。

XP并不意味着没有计划。计划是其中的一部分，它包括优先级，用户故事估计，迭代计划和任务定义。即使您是一名开发人员，您仍需要与客户一起完成这些工作。

诸如代码的集体所有权和结对编程之类的问题涉及多个方面。确定诸如编码标准之类的事情要容易得多，但这并不意味着您不必遵循它们。集体代码所有权仍然适用-所有权也是下一个开发人员-请勿编写适合您和您自己的代码。请注意，这与结对编程启用的“代码揭示了所有意图”存在一定程度的冲突-您没有该人来检查您是否正在编写可维护的代码，因此代码的文档编制也至关重要。

除了这些警告以外，许多XP设计原则仍然适用。测试优先设计，持续集成，与客户会面，重构，YAGNI，秒杀解决方案之类的事情-这些调用可以单独完成。

意识到单独XP与常规XP一样需要更多或更多的纪律。XP通常被认为是一种高度规范的方法，因为它要求人们严格遵循它试图体现的最佳实践。当您没有教练或其他人来支持所需的学科时，它可能会落入与XP有点相似的实践大杂烩中。

相关阅读：

• XP主题的变体（马丁·福勒）
• 极限编程（在c2处不同）
• 极限编程一个（在c2处不同）

我想从第一个c2链接中引用一个引号：

著名的Perl语言专家和疯狂的科学家Damian Conway认为极限编程实际上是用词不当。由于它体现了程序员所要学习的许多良好编程习惯，但几乎可以肯定会忽略，因此他认为它应该真的被称为超保守编程。