Architecture 在敏捷开发中，您如何处理；“结构不太好”；源于专注于冲刺思维的代码

我使用Scrum从事一个敏捷项目

冲刺来了又去，我们成功地完成了里程碑。该系统运行良好，足以满足当前客户的要求

然而，留给我们的是一个严重需要重构的系统，因为大部分开发都是在对未来没有太多关注的情况下进行的（相反，重点是手头的sprint）

---

如何最好地处理这个问题？Sprint致力于重构？

是的，偶尔进行重构并不是一件坏事。但是，如果您使用Scrum是敏捷的，那么您可能正在尝试遵循测试驱动开发（TDD），并且您必须记住，重构的顺序是红-绿-重构，而不仅仅是红-绿。质量差的代码不是敏捷开发的产物，而是差的敏捷开发的产物。

在我工作的地方，我们将有专门针对bug和错误的冲刺。在一定程度上，它对改进事物起到了很好的作用，并且具有持续改进的精神

---

这里还需要考虑的是，是否有客户想要但尚未要求的增强功能。客户是否真的对当前的系统感到满意，或者它是否工作得足够好，以至于他不想抱怨？

您不一定需要花费整个sprint来进行重构，它也可以在任务级别工作。当您有一个故事需要处理一些毛茸茸的代码时，请在该故事中包含一个重构任务，作为对该部分进行合理处理的先决条件。这样，您可以在特性方面取得进展，但也可以逐步完成一些重构。

对于我的团队，我通常大约每三到四个月启动一次重构冲刺。考虑到我们要运行两周的sprint，这就是大约每七个sprint进行一次重构sprint

我像其他sprint一样运行重构sprint-严格来说是2周的时间限制。有时我们甚至只运行一周的重构冲刺（当出现紧急情况时）

关于重构冲刺的说明：不要太雄心勃勃：

要意识到重构是一个无限循环：你总能找到更好的方法来做事情

如果只重构需要重构的内容的10%，那么就可以了

像对待任何其他故事一样对待重构，这样您就不得不优先考虑重构内容，并识别代码中最需要重构的地方。唯一的区别是，对于重构故事，我让开发人员设置优先级

部分重构仍然会使代码处于比根本不重构更好的状态。此外，它往往使进一步的重构更容易

当处理故事时，重构甚至在重构冲刺之外发生，但前提是重构是一个低挂果实，不会干扰故事的完成

---

这是我个人用来指导重构的。它不仅使重构变得可管理，而且还可以作为一个很好的指标，表明您何时做得过火。

您对“完成”有定义吗

当您完成编码并准备签入时，您应该已经满足了团队对“完成”的定义

此定义应包括满足验收标准/代码审查/测试审查/以及满足商定的编码标准

如果在几次冲刺之后，您的代码库需要进行认真的重构，我建议您定义“完成”需要评审

---

这里有一篇来自Scrum Alliance的文章，如果我可以的话，它是关于定义你的

+1的。当敏捷得到了一个糟糕的代码架构的代表，当敏捷和TDD被明确地设计为通过持续改进来改进代码架构时，这让我很难过。我不同意，TDD通常并不等同于良好的系统架构。此外，TDD应作为“适当时”的方法使用。虽然我同意红-绿折射仪，但我相信很多人都会对这一点产生兴趣，从而显著延长开发时间。TDD非常适合专注于应用程序的微观部分。很明显，它将扩展并发展成一个设计更完善的工作流，但这并不总是产生一个好的宏设计。Sprint级别的折射率对于这一点至关重要。@Chance：（1）任何方法应用不当或误用都会导致系统架构和编写不当。（2） TDD是一种通常在整个敏捷过程中应用的开发方法，我的评论是关于敏捷开发的输出，而不是具体的TDD。如果您试图使用TDD来解决更高级别的问题，如体系结构问题，您将失败。TDD从来都不等同于架构良好的系统，就像驾驶考试从来没有衡量过烹饪煎蛋饼的能力一样！但是做得好的TDD并不会加剧这种情况。如果您的组织正在寻求实现与高性能（又称超高效）SCRUM团队相关的生产率提高，那么这可能是一件坏事。Jeff Sutherland非常清楚此类性能提升的先决条件，包括比本文描述的更严格的“完成”定义。Carl Manasters的回答提供了更多细节。