策略模式是否主要基于软件会发生变化的事实？
1）因此，在今天的环境中，如果变化完全未知且无法预见，该怎么办？那时，策略模式是不适合添加（在那一刻）？
2）如果项目经理希望在2天内完成，或者尽快完成，或者你完成得越快，看起来越好，性能评估越好。如果您在不使用策略模式的情况下编写它，您可能能够在2天内完成，否则，PM可能会在延迟时皱眉并将其归因于性能不佳。在这种情况下，您如何平衡实施速度与可维护性？
3）在合同工作下进行编程也是如此 - 持续2个月或3个月。一些程序员或之前的程序员是否会忽略可维护性以便尽快完成？管理者是否真的关心项目是否具有100％的功能，是否具有可维护性？
答案 0 :(得分：6)
对于1），我建议不要使用策略模式。过度设计现在变得非常普遍，并且对可维护性本身几乎没有或产生负面影响。我遇到的系统设计易于扩展，但最终扩展从未实现。
Jeff Atwood对KISS and YAGNI提出了一些建议。
答案 1 :(得分：3)
Re 2）和3），是的，你会发现很多非职业公司的非职业行为，例如：由项目经理和承包商，以及许多其他所谓的专业人士（如果可以的话，避免这些不正常的公司）。
Re 1），是的，在敏捷开发方法中，“无情地重构”是常态，优秀的测试赋予这种重构保证，引入战略模式的恰当时间恰好是第一次需要 - 否则，YAGNI适用，过早引入模式将是过度工程的一个例子。
答案 2 :(得分：2)
好，伤心地说，项目经理不关心的可维护性。如果你有能力从一个工作岗位转到另一个工作岗位，快速砍掉东西，或多或少地工作（或者至少看起来像是在工作），然后去找你的下一份工作。
（这是非常愤世嫉俗的，但不幸的是真的。我为没有提供解决方案的建议而道歉，但这比我今晚要做的更多。）
答案 3 :(得分：1)
你说的是不同的事情。
首先，我认为你应该始终记住YAGNI，所以如果绝对没有暗示你会需要它，你可能不会，所以不要使用它。
如果知道这种变化已经发生，但你真的不知道它将采取的形式，那么尝试过度设计将是一个障碍。如果有可能在两天内为你的经理提供它，但是你浪费了两周时间试图将其塑造成一种策略模式，那么难怪他会生气。
只有在你需要时才使用模式，或者你有理由相信你会需要它们，如果你不这样做，那么就会有足够的时间来重构，并记住重构可以是计划之后，当需要的时候。
另一个说明。 使用设计模式本身并不会增加代码维护性。事实上，它可以成为反模式。您可以开发没有模式的完美可维护代码，因为您的代码可能不需要模式...
最后......我总是喜欢谈论经理。当然，他们中的一些可能是Dilbert的，但不要低估你的经理。比你认为你的经理比你更多的信息，所以如果他说它必须在两天内完成......也许这是有充分理由的。它无法为您在破产公司中销售的产品提供完美，干净，可维护的代码。
答案 4 :(得分：1)
我认为你的担忧是没有资金的。在我看来，这是一个很容易重构的模式。按照此时指定的方式编写算法，并尝试隔离可能的更改位置。如果是这种情况，请使用常识OOD规则并稍后添加策略。