什么时候应该消除复杂性？

通过在需要之前实施设计模式来过早引入复杂性不是一个好习惯。

但是，如果您遵循所有（或什至大部分）SOLID原则并使用通用的设计模式，那么随着功能或需求的添加或更改，以使您的设计保持所需的可维护性和灵活性，您将引入一些复杂性。

但是，一旦引入了这种复杂性并像冠军一样工作，何时将其删除？

例。我有一个为客户编写的应用程序。在最初创建时，那里有几种向员工加薪的方法。我使用了策略模式和工厂来使整个过程保持整洁。随着时间的流逝，应用程序所有者添加或删除了某些升高方法。

时间流逝，新主人接管了。这个新主人刻薄了鼻子，保持一切简单，只有一种加薪的方法。

不再需要策略模式所需的复杂性。如果我现在按照需求在哪里编写代码，那么我不会介绍这种额外的复杂性（但请确保在需要时我可以花很少的精力或根本不用做任何工作来引入它）。

那我现在要删除策略实施吗？我认为这个新主人不会改变加薪的方式。但是应用程序本身已经证明了这可能发生。

当然，这只是新所有者接管并简化了许多流程的应用程序中的一个示例。我可以删除数十个类，接口和工厂，并使整个应用程序更加简单。请注意，当前的实现确实可以很好地工作，并且所有者对此感到满意（由于所讨论的复杂性，我能够如此迅速地实现她的更改感到惊讶甚至高兴）。

我承认这一怀疑的一小部分是因为新所有者很可能不再使用我了。我真的不在乎其他人会接手这件事，因为它并不是一个巨大的收入来源。

但我确实关心2件（相关的）事情

1. 我有点担心，新维护者在尝试理解代码时将不得不加倍努力。复杂性就是复杂性，我不想激怒追随我的心理狂。

2. 但是，更令我担心的是竞争对手看到了这种复杂性，并认为我只是实施设计模式来增加工作时间。然后散布这个谣言来伤害我的其他生意。（我听说过此事。）

所以...

总的来说，即使以前需要的复杂性行之有效，并且历史上已经证明了对这种复杂性的需求，但是否应该删除它却没有迹象表明将来会需要它呢？

即使上面的问题通常被回答为“否”，如果将项目移交给竞争对手（或陌生人），消除这种“不必要的”复杂性是否明智？

在某些方面，我认为这很大程度上是业务决策，不一定基于代码本身。要考虑的一些事情：

• 您得到报酬进行更改吗？
• 该代码当前是否按预期运行？
• 代码是否存在任何安全性或性能问题？
• 技术债务的金额是否超过修复债务的成本？
• 如果您将代码保持原样，实际上可能会发生什么？
• 有或没有重构，将来会出现什么问题？
• 代码对您和您的企业有多大的责任？

您最有能力回答这些问题。但是，根据您的描述，我不知道我是否会费心重构和简化事情，因为这听起来不值得您花时间。如果当前可行，那么客户会很高兴，并且您不希望因更新所有内容而获得报酬，那么就顺其自然，继续从事创收活动。

简而言之，对这两种途径进行成本效益分析和风险评估，并采取最安全，最有效和最有利可图的行动方案。

难道不是要删除此代码并将其替换为一些简单的东西，以便将来为客户需要考虑并付费的功能进行编码吗？

您可能会从其他开发人员那里学到一些有用的东西，但是不太可能找到其他客户的应用程序以将其插入。

您无法避免闲聊竞争对手的代码。他们试图招募负面客户看起来很愚蠢。

俗话说：“如果没有破裂，就不要修理”。

该规则背后有一些基本原理。其中一些可能是“简化”可能会带来引入新的，不同的，甚至可能更大的错误的风险，可能会使开发时间与其他更有价值的工作相去甚远，并且对于某些意外的未来商机可能完全是错误的更改，出现。

如果有足够的商业价值使此代码可移植且更易于维护，则请确定该值是否真的足以将当前代码视为“已损坏”。如果计划进行大规模的业务扩展，或者您怀疑隐藏在可能导致业务瘫痪的复杂性中的潜在错误，那很可能是这样。

首先，如果该应用已经被新所有者接管，则可能会再次发生。下一位拥有者可能会再次开始使用目前无法从中受益的复杂性。

除此之外，对工作代码进行不重要的更改总是会带来风险，因此（如其他人所述）客户应该同意（并为此付费）。如果当前的“额外”复杂性没有引起任何明显的，可衡量的缺点（例如性能问题），则没有充分的理由消除它。

（仅）（不）仅根据竞争对手的谣言聘用您的客户，恕我直言不值得拥有，除非您迫切需要收入。您有合理和合理的理由来按自己的方式实施该应用程序，任何认真的客户都可能理解这一点。某个不愿意或根本不想问您的人，一路上可能会给您带来更多的麻烦，而不是工作的价值。

总的来说，即使以前需要的复杂性行之有效，并且历史上已经证明了对这种复杂性的需求，但是否应该删除它却没有迹象表明将来会需要它呢？

没有。

即使上面的问题通常被回答为“否”，如果将项目交给竞争对手（或陌生人），消除这种“不必要的”复杂性也是明智的

否。为什么要浪费时间来解决低优先级的问题？保留在那里的代码没有害处。

至于您的问题：什么时候应该消除复杂性？

我的看法是，如果它没有破裂，请不要修复它。

为了消除复杂性，必须满足以下条件：

1. 删除的部分必须独立于程序。如果周围的程序与所讨论的代码之间存在任何依赖关系，则仅除去复杂性将不起作用
2. 不幸的是，如果看起来很复杂，那么很可能这些部分不是独立的，并且当您删除该部分时，依赖关系会破坏您的程序
3. 删除所有依赖项将花费一些时间，因此在您评估该操作是否值得付出努力时需要考虑时间
4. 在大多数情况下，这样做是不值得的，但您只需要决定不让任何新代码使用旧代码即可

我认为这里还有一些更大的工作...可扩展性

您所说的就是可伸缩性。编码是否复杂并不重要，应用程序是否可以基于新的业务规则或已更改的业务规则进行开发都至关重要。如果下一个所有者想要完全不同的东西会发生什么。

所以，我说保留代码并将其记录下来。这是如何利用应用程序的功能。

总的来说，即使以前需要的复杂性行之有效，并且历史上已经证明了对这种复杂性的需求，但是否应该删除它却没有迹象表明将来会需要它呢？

消除复杂性存在着努力和风险。如果这比增加的工作量和维护过于复杂的代码的风险高，那么请保留它。否则，将其删除。但是，很难估计这些风险。

我还要补充一点，您可以通过在代码中记录为什么首先使用设计模式Strategy 来减轻维护难度更大的风险。我个人认为，任何设计模式都应可追溯到明确的要求（功能性或非功能性）。

即使上面的问题通常被回答为“否”，如果将项目移交给竞争对手（或陌生人），消除这种“不必要的”复杂性是否明智？

您的竞争被浪费了很多时间正是您记录复杂性的原因。如果您记录并证明了（根据特定的客户要求）任何模式的使用，那么您将被覆盖。如果您不能用客户的要求来证明一种模式是合理的，那么这看起来就像是过度设计或模式化。

如果需求发生变化，则可以合理地放弃它，因为有可能破坏代码（或通过外科手术去除图案的工作量）。

我认为最好区分意外复杂性和本质复杂性，因为模式经常同时涉及到这两者。

也就是说，您需要支持不同的算法来决定加薪是必不可少的复杂性（要解决的问题的一部分）。策略模式使代码的维护更加容易，但是，硬编码的if / then替代策略仍然可以使用。我在硕士课程中做过练习，在这些课程中，学生找到了将策略应用于开源项目的机会。应用策略时，复杂性不一定会更好/更糟（因为这是必不可少的复杂性）。有时，对策略的理解可能会更加困难，因为代码会被多态性分成多个类，而不是一个大的if / then / else块。

理想情况下，当模式提供的好处大于缺点的代价时，它就会起作用。同样，很难量化这些东西。通常，一种模式会使开发人员感到高兴（不仅仅是因为它使添加新的提升策略变得更加容易，而且使开发人员对应用了某种模式感到兴奋不已）。很难向客户展示它如何使他们受益。

客户不在乎甚至不了解细节。对于新所有者在其流程中使用KISS的情况，这是她减少了基本的复杂性，这也将对软件解决方案产生影响。