Architecture 您如何在保持敏捷的同时避免技术债务，即：避免违反YAGNI和避免BDUF？

技术债务

雅格尼（你不会需要它的）

BDUF（前端大设计）

更新：为了澄清这个问题，我想我也可以这样说，并保留我的意思：

“作为一名敏捷实践者，您如何在每次迭代中在“快速和肮脏”（试图遵守YAGNI时无意中冒技术债务风险）和过度工程（BDUF）之间找到正确的平衡？” （TDD）方法有助于解决这些问题

为什么?

• 您只需编写足够的代码即可通过下一次测试
• 我认为可测试代码更干净
• 设计必须融入测试，这有助于保持设计的重点
• 当您确实需要更改（重构）时，您需要依赖测试

不管考试是什么时候写的（之前还是之后），我都会发现写作 测试帮助你做出实际的决定。例如，我们选择设计A或B是因为

---

A更易于测试。

这就是为什么写一些漂亮的“学术论文”总是比较容易的原因，这些论文讨论敏捷开发的优点，什么是“最佳实践”等等

这就是为什么你会发现很多“合适的工程师”在创造新的软件工程技术

过程很重要，保持最佳实践很酷，但比其他任何事情都重要，常识驱动设计过程。软件是由人开发的，因此YAGNI应该：

我可能不需要，但也许我会，因为在我的具体业务/公司/部门，这件事确实发生了，或者我需要它，但我只是没有时间，没有那么快和肮脏的黑客来赚钱和保住我的工作，或者我可能需要它，以后重构将是一件痛苦的事情，花费的成本是现在从头开始的10倍，而我现在有时间

所以，运用你的常识，相信它，或者相信为你工作的人的常识。不要把每一篇学术论文都当作已证明的事实，经验是最好的老师，你的公司应该根据时间和自己的经验改进他们的方式或制作东西

---

编辑：顺便说一句，TDD与您在构建测试之前甚至还不知道是否需要它们的YAGNI相反。说真的，别再听学术了！！生产软件没有神奇的方法。

XP的“传统”答案是重构与自动单元测试相结合

但从哲学角度来说，这是一个非常有趣的问题。我不认为你需要避免技术债务，只是把它保持在一个可控的水平。史蒂夫·麦康奈尔（Steve McConnell）的文章在这方面做得很好——这个类比之所以有效，是因为在一家公司建立财务债务是正常的，也是可以接受的，只要你接受成本和风险——技术债务也是可以接受的

也许答案本身也在于雅格尼的原则。你不需要还清技术债务，直到你还清为止，那就是你进行重构的时候。当你在一个有技术债务的系统领域做大量工作时，看看重新设计会带来多大的短期影响。如果这足够让它变得值得，就把它还清。麦康奈尔关于保持债务清单的建议将帮助你知道何时应该考虑这一点

---

我不认为这有一个绝对的答案——就像许多事情一样，这是一个基于你的经验、直觉和你在每个特定情况下的分析的判断。当然，敏捷会让你在任何给定项目中都保持TD低

---

事实上，您正在实现客户想要的，即通过他们的反馈，将TD保持在最低水平，

几周前，根据您对“在HanselMinutes上完成”的定义，对技术债务进行了一次有趣的讨论--。该节目的基本内容是，如果你重新定义“完成”以提高感知速度，那么你将积累技术债务。由此产生的推论是，如果您对“完成”没有一个正确的定义，那么您很可能会获得一个在发布之前需要完成的项目列表，而不管设计方法如何。

如果您坚持敏捷的“计划，做，适应；计划，做，适应”思想（迭代，迭代评审）默认情况下，您会避免这些事情。BDUF恰恰相反，如果你真的是敏捷的，你就不会自动成为BDUF

发布和迭代计划会议的目的是确保为该迭代向项目添加最有价值的特性。如果你记住这一点，你将免费避开雅格尼

我强烈推荐Mike Cohn关于敏捷规划的书籍：

---

更新：在您澄清在迭代中避免使用YAGNI和BDUF后

BDUF…如果在开始工作之前我觉得某个功能没有明确定义，我会创建一个小的“功能”或故事来说明所需工作的设计类型部分。因此，也许小故事的估计值是1，而不是真实故事的5。这样，设计就被时间限制在了较小的故事中，您将被驱动到功能本身

为了避免违反YAGNI，我会非常清楚客户对迭代中的功能的期望。只做符合客户期望的工作。如果您认为应该添加一些额外的功能，请为其创建一个新功能，并将其添加到要完成的任务中。然后你会说服客户看到它的好处；正如客户希望在某个时间点完成某个功能一样

你好像说“雅格尼”意味着“快而脏”。我看不出来

作为一名敏捷程序员，我实践测试驱动开发、代码审查和持续集成