软件设计稳定性、YAGNI和敏捷

Question

我已经满足了良好的系统设计的标准，因为它相对于需求的变化是稳定的。

小雷克。改变应该引起设计上的小变化。

然而，我的直觉是，几乎对于任何有点复杂的软件系统，都有可能在需求中声明一组小的更改，这会导致软件中不可接受的大量更改。

这种感觉是建立在个人经历的基础上的，尽管不是很好，而且时间表经常被打破。

在出现强烈分歧的情况下，社区可以反对这一说法。

但这个问题只有在你同意的情况下才有意义。

YAGNI原则可以很好地对抗过度设计，敏捷方法将其引入到软件开发的整个过程:系统是逐步发展的，这完全符合我从这个帖子开始的稳定性概念。

但是..。然而，如果我们同意存在一些不稳定点，难道我们不应该从一开始就定位这个例子来理解它的含义吗？如果我们以敏捷增量的方式设计系统，怎么可能呢？！

P.S.与我的同事进行对话的部分内容：

• 增量式软件开发没有什么问题。
• 在好奇号的固件登陆火星后，你能想象改变它的架构的成本吗？
• 嘿，但是罐头和固件都变了！
• 是的，但在那之前，他们仔细地设计了这个特性。如果not...that是没有归宿的话。

Answer 1

我认为关键是在应用程序中封装可能的更改源。

在某种程度上，变更是好的，因为它表明软件正在增长(新的需求)或变得更好(bug修复)。

了解变化可能发生的地方(AKA )。“了解您的业务领域”)，然后您可以构造应用程序来封装这些更改区域。当你说localize this cases to understand the implications from the very beginning时，我认为这就是你所考虑的。

你仍然面临着灾难性变化的危险。导致过多代码更改的需求变化)，但这始终是软件开发中的一个风险。

从设计和编程经验中获得的智慧是我们知道如何封装变化的领域。对于当前的需求以及项目的更广阔的视野，有一个坚实的理解也是至关重要的。将您的应用程序愿景一次锁定在一个sprint中将增加您发生灾难性更改的风险。敏捷促进了对sprint的关注，也促进了对总体方向的理解。