“重新发明轮子”反样式很常见-无需使用现成的解决方案，而是从头开始编写自己的解决方案。代码库不必要地增长，执行相同功能但接口略有不同的接口略有不同，浪费了时间来编写（和调试！）易于使用的功能。我们都知道这一点。
但是在频谱的另一端却有些东西。当您不用编写包含两行代码的函数，而是导入框架/ API /库，实例化，配置，将上下文转换为框架可接受的数据类型，然后调用一个完全满足您需要的函数时，千兆字节抽象层下的两行业务逻辑。然后，您需要使该库保持最新状态，管理构建依赖关系，使许可证保持同步，并且其实例化代码的时间比仅“重新发明轮子”的时间长十倍且更加复杂。
原因可能会多种多样：无论成本如何，管理层都严格反对“重新发明轮子”，尽管需求与需求之间存在一点重叠，但有人仍在推动他们喜欢的技术，系统的主要模块的角色逐渐减少，或者期望框架的扩展和更广泛使用的概念，这些概念永远不会到来，或者只是误解了“重量”，而一些导入/包含/加载指令却在“幕后”进行了装载。是这种反模式吗？
（我不是试图在是非是对，或者是真正的反模式或基于观点的任何情况下开始讨论，这是一个简单直接，客观的命名问题。）
编辑：建议的“重复项”讨论过度设计自己的代码以使其“为一切准备就绪”，完全与外部系统分开。在某些情况下，它可能源于此，但通常它源于“厌恶重新发明轮子”-不惜一切代价进行代码重用；如果存在解决问题的“现成”解决方案，则无论解决方案的适用性和成本如何，我们都将使用它。相对于代码复制，在原则上更倾向于创建新的依赖项，与创建和维护新代码的成本相比，完全不考虑这些依赖项的集成和维护成本。
#1 楼
否。没有常用的反模式名称覆盖您所描述的内容。评论
出现的想法，建议和讨论数量众多，这实际上是正确的。
– SF。
17年4月19日在10:39
我觉得这很脏。
– SF。
17年4月19日在16:11
?？ “没有XXX”是一个非常有力的陈述，很难证明，尤其是考虑到评论中提到了几位候选人。
– AnoE
17年4月19日在17:20
@AnoE“这种反模式是否有通用名称？”所述评论和回答中的证据严重暗示没有证据。是的，它不会回答标题，但会回答问题本身。
– Kroltan
17年4月19日在17:27
@AnoE你不能证明是负面的，hon。也许这个术语藏在婆罗洲的一块岩石下，而我们还没有跌落呢？对我来说，有十个答案而不是一个答案有十亿个赞。
–user251748
17年4月19日在17:30
#2 楼
金锤金锤之所以被选择只是因为它很漂亮。
资料来源：xkcd 801
（尽管投票不赞成，我仍然支持这个答案。这可能与重新发明完全相反从语义上讲轮子，但它适合问题中提到的每个示例）
评论
已投票，您也可以从Wikipedia上获取它：en.wikipedia.org/wiki/Anti-pattern，en.wikipedia.org/wiki/Law_of_the_instrument
– Pierre.Sassoulas
17年4月19日在9:19
如果我有代表，我会拒绝投票。它并没有整体上回答问题，但是提供了一个（准确的）术语，仅回答了其中一种建议的方案。
–大卫
17年4月19日在10:14
要求相反。这就像坚持认为“ Becquerel”（辐射，单位为s ^ -1）可代替音乐使用的是Hertz（hz，单位为s ^ -1），因为它们都表示“每秒”。
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
17年4月19日在11:58
@ThorbjørnRavnAndersen我那天听到了一些非常危险的音乐。
–user251748
17年4月19日在17:40
#3 楼
罗伯特·马丁（Robert Martin）使用“框架约束”一词来指称此反模式的最明显负面影响。由于我不认为模式本身有任何通用名称，因此对于大多数用途而言，对此结果进行引用就足够了。评论
存在可加快开发过程的框架。它们就像一枚助推火箭：一经使用便消耗exp尽。解决方案是-发布版本一，现在我们在哪里？是的，开发软件。下一个！维护是一个单独的问题，我认为这些天应该不重要了。急于求助，将下一个框架带到下一个解决方案。
–user251748
17年4月19日在17:35
#4 楼
Wikipedia页面上的“ Invented Here”描述了一种稍微不同的情况，但最终结果却非常相似。描述了当可以在其中找到等效功能时团队对创建自己的代码的厌恶。与“ Not Invented Here”（此处未发明）相对时，会引起感觉。IMHO几乎是Reinventing the wheel的代名词。#5 楼
我听说过“购买与构建”和“在这里发明”这两个名称作为反模式名称，它们倾向于反对内部开发内容，即使这样做可能有意义。 （尽管“买进还是买进”一词应该表示可行的选择之间的一种选择，但我发现当有人认为“购买”是正确的选择时，通常会提到它。）#6 楼
不要用大炮杀死蚊子
孔子
又名杀人狂
评论
（英国）常见的英语短语是“用大锤开裂螺母”。
–nigel222
17年4月19日在11:50
相关Monty Python草图
–Steadybox
17年4月19日在14:43
还：“用坦克猎鹿”
–犹他那
17年4月19日在15:10
“用锤子拍打苍蝇”
–user251748
17年4月19日在15:45
不要用锤子杀死苍蝇
– jeffmcneill
17年5月5日在11:11
#7 楼
膨胀是一个广义术语，但可以包含您所描述的内容。由于需要进行所有额外的转换和抽象，我们的软件变得过于复杂（膨胀），并且复杂性和依赖性本身都导致性能降低/效率降低和资源消耗（磁盘，带宽）增加。如果我们愿意，我们可以用膨胀的依赖项来澄清。
#8 楼
我认为使用大锤开裂螺母非常接近。这是可能的，但是要以这种方式破解一个螺母需要花费大量的工作，而不会发生许多可能的不良副作用。 （而且还有一大堆要破解的坚果……）该短语还具有不算行话的优点，因此对于向不懂行话的人提供线索可能很有帮助。没关系。
顺便说一下，依赖地狱有一个区别。如果有人已经将所有复杂性包装在一个封装中，该封装将创建简单，清晰，易于使用的接口，并且提供的CPU周期损失或内存使用情况不会过多，并且将来不太可能修改封装的代码需要，那么剩下的一个反对使用它的参数就是它可能引起的依赖地狱。
#9 楼
我不认为有确切的相似之处，但我想说过度设计或过度工程是最接近的。按照您的描述。使用库而不是编写自己的代码来实现相同的功能几乎永远不会有害。
即使在您的假设示例中，也不一定需要使用库来替换“两行代码”，但是这不太可能给您带来很多麻烦-如果它确实是旨在执行与您的两行代码相同。
做简单事情的库也很简单。
使用复杂的库执行简单的操作可能意味着您在尝试实现比实现所需功能还要更多的事情。 />例如不需要的内置功能，为可能永远不会出现的未来做准备等等。
#10 楼
如果您尚未重新发明轮子，则很可能是使用供应商或第三者提供的一组现有轮子。如果这是反模式，则通常称为供应商锁定。
评论
我真的不觉得这是同一回事。供应商锁定是一个特定的负面结果，具体取决于供应商的解决方案，无论选择哪种方式，使用供应商是否具有成本效益。当集成成本高于仅从头开始开发新解决方案的成本时，OP会更多地询问选择第三方解决方案的术语（在这种情况下，供应商锁定甚至可能不会发生）开发新的解决方案而不是依赖供应商便宜）。
–本
17年4月19日在1:17
@Ben-好吧，我更喜欢框架绑定，而不是供应商锁定。这个问题是基于观点的，这是我想到的第一件事。
–乔恩·雷诺（Jon Raynor）
17年4月19日在17:52
#11 楼
工作安全性？您提到了保持事物同步的所有努力，等等。有些人宁愿管理其他人的代码，也不愿自己编写代码。经理尤其如此。
评论
依赖地狱。那是我能想到的最接近的。@Machado：很好，尽管我会说“依赖地狱”是这种反模式丰富的直接结果。如果系统极其复杂，则可能是复杂性的直接结果。
我将其称为Feature_creep或Scope_creep的“依赖关系爬行”，其中越来越多的本来不需要的功能被添加到了产品中。
左垫惨案是这种综合症在行动中的真实例子。
我建议我们开始将其统称为LeftPad。