敏捷过程中软件共性的提取

Question

最近，我有机会从事一个遵循敏捷过程的大型软件项目。当我们开始做这个项目的时候，很多软件需求都不清楚。然而，软件领导犯了一个错误，即开发了一个框架，该框架基本上提取了共同点，并将它们放在一个超类中。随着项目的进展，许多需求变得清晰起来，许多现有的需求发生了变化，这就导致了我们的“框架”不断发生变化。

我的问题是，在这种情况下我们应该做些什么。

1. 提取共性，只有当所有需求都明确之后。
2. 在项目完成之前，一定要尝试任何代码优化。
3. 跟随流程，并随着需求的变化而调整代码。

有什么反模式来描述这种情况吗？很多开发人员对将公共函数迁移到超类有兴趣？对此的一般反馈是什么？

亲切的问候

Answer 1

极限编程(敏捷开发的一种味道，尽管现在不像过去那么流行)有YAGNI的原则--“你不会需要它”。这建议不要预先创建这样的框架，也不要创建任何不能直接支持当前故事的框架。有关更多信息，请参见http://c2.com/cgi/wiki?YouArentGonnaNeedIt。

当然，这有可能走得太远。如果一个项目可能需要日志记录/跟踪，那么需要等待很长一段时间，直到您有了使用日志的可维护性说明，然后才创建日志框架，然后返回并使用跟踪点对所有类进行测试，而不是在编写代码时理所当然地这样做。

所以你需要务实，创造出正确数量的“你预见到需要的东西”。我认为多少才是正确的数额，你只能凭经验来判断。

就你的三种选择而言，我想这是最接近第三位的。当您了解更多有关问题和软件结构的信息时，重构代码并不是件坏事。也就是说，您的小规模设计(封装、分离关注点等)是好的，这样每次更改都不会涉及数十个复杂的编辑，并且您有很好的测试，这些测试涵盖了足够多的功能，但与实现并没有太紧密的联系。然后，当您的设计发生变化时，您可以自信地重构。

Answer 2

太难了。我去过那里几次了。这很难，因为通常我们(作为开发人员或架构师)应该努力收集需求，front...my的队友和我通常会说，如果没有需求，我们就不应该编写一行代码，也不应该做出任何设计决策。这是绝对正确的，但在现实生活中，它变得有点复杂，有时客户甚至不知道他们的want...however，执行委员会想要让客户高兴，并使他们相信我们是最适合他们的项目(事实上我们是)的滚动。

从那时起，我们开始构建一个“非常灵活”、可维护、可伸缩的系统，几个月后需求发生变化，我们不得不重新设计系统的基础。您可能希望有一个神奇的设计模式/指南来遵循和防止this...well，不幸的是，没有。

您总是可以将这种需求的影响降到最低，但是无论您构建了多么灵活的系统，您都必须考虑到一组基本需求，如果需求发生变化，那么系统可能也需要进行更改。