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

Question

最近，我有机会参与一个遵循敏捷流程的大型软件项目。当我们开始研究项目时，很多软件要求都不清楚。但是，软件负责人错误地开发了一个框架，该框架基本上提取了共性并将它们放在超类中。随着项目的进展，许多要求变得清晰，许多现有要求发生了变化，这当然导致我们的“框架”不断变化。

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

1. 只有在所有要求都明确后才能提取共性。
2. 在项目完成之前，请尝试任何代码优化。
3. 使用流程，并根据需求的变化调整代码。

是否有描述此场景的反模式？很多开发人员都对将常用功能转移到超级课程感到着迷？对此有何一般反馈？

亲切的问候

Answer 1

极限编程（敏捷开发的一种风格，虽然现在不像过去那么流行）但却有YAGNI的原则 - “你不需要它”。这建议不要预先创建这样的框架，或任何不直接支持当前故事的框架。有关详情，请参阅http://c2.com/cgi/wiki?YouArentGonnaNeedIt。

当然，这可能会走得太远。如果一个项目可能需要，比如记录/跟踪，那么等到你有一个使用日志的可维护性故事，然后创建一个日志框架然后返回并检测所有项目将会是很多工作。带有跟踪点的类，而不是在编写代码时按理所当。

所以你需要务实，只需创建正确的数量的“你预见到需要的东西”。我认为合适的金额是多少，你只能通过经验来判断。

就你的三个选项而言，我猜这是最接近三号的。在了解有关问题和软件结构的更多信息时重构代码并不是一件坏事。提供，即你的小规模设计（封装，关注点分离等）是好的，这样每次改变都不涉及几十个复杂的编辑，并且你有很好的测试，它涵盖了足够的功能，但不是与实施紧密联系在一起。然后，随着设计的变化，您可以放心地进行重构。

Answer 2

这很难。我去过那里几次。这很难，因为通常我们（作为开发人员或架构师）应该努力预先收集需求...我的队友和我通常会说没有要求我们不应该编写一行代码或做出任何设计决策。这是绝对正确的，但是，在现实生活中它有点复杂，有时客户甚至不知道他们想要什么......但是，执行委员会希望让客户满意并让他们相信我们最适合他们的项目（实际上我们是）通过滚动球。

此时我们开始构建一个“非常灵活”，可维护，可扩展的系统，然后几个月后需求发生变化，我们不得不重新设计系统的基础。你希望有一个神奇的设计模式/指南可以遵循并防止这种情况......好吧，不幸的是，没有。

您始终可以最大限度地减少此类需求蔓延的影响，但无论您构建系统的灵活性如何，您始终必须考虑到一组基本要求来构建它，如果需求发生变化，那么系统可能需要也要改变。