与“重新发明轮子”相对的反模式的名称是什么？[关闭]

“ 重塑方向盘 ”反模式非常常见-无需使用现成的解决方案，而是从头开始编写自己的解决方案。代码库不必要地增长，执行相同功能但接口略有不同的接口略有不同，浪费了时间来编写（和调试！）易于使用的功能。我们都知道这一点。

但是在频谱的另一端。如果不编写包含两行代码的函数，而是导入框架/ API /库，实例化，配置，将上下文转换为框架可接受的数据类型，然后调用一个可以完全满足您需要的函数，千兆字节抽象层下的两行业务逻辑。然后，您需要使该库保持最新状态，管理构建依赖关系，使许可证保持同步，并且其实例化代码比“重新发明轮子”要长十倍且更复杂。

原因可能多种多样：无论成本高低，管理层都严格反对“重新发明轮子”，尽管与要求之间存在边际重叠，有人推销他们所钟爱的技术，该系统以前主要模块的作用减弱，或者期望扩展和扩大使用这个框架，它永远不会到来，或者只是误解了“重量”，而一些导入/包含/加载指令却是“幕后”。

这种反模式有通用名称吗？

_{（无论是对还是错，或者它是一个真正的反模式或基于观点的任何内容，我都不会尝试进行讨论，这是一个简单明了的客观术语。）}

编辑：建议的“重复项”讨论过度设计自己的代码以使其“为一切准备就绪”，完全与外部系统分开。在某些情况下，它可能源于此，但是通常它源于“厌恶重塑轮子”-不惜一切代价进行代码重用；如果存在解决问题的“现成”解决方案，则无论解决方案的适用性和成本如何，我们都将使用它。原则上赞成创建新的依赖项而不是代码复制，而与创建和维护新代码的成本相比，完全不考虑这些依赖项的集成和维护成本。

否。没有常用的反模式名称覆盖您所描述的内容。

金锤

选择金锤只是因为它精美而选择。执行既定任务既不合算，也不高效。

来源：xkcd 801

（尽管投票否决，我仍然支持这个答案。从语义上重新发明轮子可能并不完全相反，但它适合问题中提到的每个例子）

罗伯特·马丁（Robert Martin）使用“ 框架绑定 ”一词来表示此反模式的最明显负面影响。由于我不认为模式本身有任何通用名称，因此对于大多数用途而言，对此结果进行引用就足够了。

Wikipedia页面上的“ Invented Here ”描述了一种稍微不同的情况，但是最终结果却非常相似。描述当可以在其中找到等效功能时团队对创建自己的代码的反感。

我会说这个名字有点误导。与“ Not Invented Here”（此处未发明）相对时，会引起感觉。IMHO几乎是Reinventing the wheel的代名词。

我听说过“ 购买与构建 ”和“ 在这里发明 ”作为反模式名称，以偏向于内部开发，即使这样做可能有意义。（尽管“买进还是买进”一词应该表示可行的选择之间的选择，但我发现当有人认为“买进”是正确的选择时，通常会提到它。）

请勿使用大炮杀死蚊子

孔子

又名过杀

膨胀是一个广义术语，但可以包含您所描述的内容。由于需要进行所有额外的转换和抽象，我们的软件变得过于复杂（膨胀），并且复杂性和依赖性本身都导致性能/效率降低和资源消耗（磁盘，带宽）增加。

如果我们愿意的话，我们可以用膨胀的依赖项来澄清。

我认为使用大锤开裂螺母非常接近。这是可能的，但是要以这种方式破解一个螺母需要花费大量的工作，而不会发生许多可能的不良副作用。（还有一整袋坚果要破解...）

该短语还具有不计算行话的优点，因此它可以为没有提示的人提供线索非常有帮助。

顺便说一句，在依赖关系hell方面有一个区别。如果有人已经将所有复杂性包装在一个封装中，那么它可以创建简单，清晰，易于使用的接口，并且提供的CPU周期损失或内存使用情况不会过多，并且将来不太可能对封装的代码进行修改需要，那么剩下的反对使用它的理由就是它可能引起的依赖地狱。

我认为没有确切的相似之处，但我想说过度设计或过度工程是最接近的。

至少，我会说，这是我遇到类似于您所描述的内容时真正发生的事情。

使用库而不是编写自己的代码来实现相同的功能几乎永远不会有害。

即使在您的假设示例中，也不一定需要使用库来替换“两行代码”，但是这不太可能引起您很大的麻烦-如果它确实是一个库，其意图与您的两行代码相同。

一个库做一件简单的事情也将很简单。这不太可能使您感到疑问。

使用复杂的库执行简单的操作可能意味着您在尝试实现除实现所需功能之外的其他事情。

例如不需要的内置功能，为可能永远不会出现的未来做准备等。

这里的问题并不是真正地重新发明轮子本身。

如果您还没有重新发明轮子，则很可能是使用供应商或第三者提供的一组现有轮子。

如果这是反模式，则通常称为供应商锁定。

就业保障？
您提到了使事物保持同步的所有努力，等等。有些人宁愿管理其他人的代码，也不愿编写自己的代码。经理尤其如此。