重新发明轮子真的那么糟糕吗？

#1 楼

取决于..
与所有内容一样，它取决于上下文：
当以下情况很好：

框架或库太重，并且只需要有限的功能。推出适合自己需求的超轻量级版本是一种更好的方法。
当您想了解和学习复杂的东西时，自己滚动是很有意义的。
您可以提供一些与众不同的东西的实现没有。

以下情况很不好：

功能已经存在并且稳定且广为人知（受欢迎）。
您的版本未添加任何功能新。
您的版本引入了错误或限制（例如，您的版本不是线程安全的）。
您的版本缺少功能。
您的版本的文档质量较差。
您的版本为与要更换的产品相比，缺少单元测试。

#2 楼

我认为开发人员有意“因为他更喜欢自己的方法”而重新发明轮子的情况很少见。大多数情况下是出于无知，有时是出于固执。

不好吗？是。为什么？因为现有的车轮很可能随着时间的流逝而经过精心设计，并且已经在许多情况下针对大量不同类型的数据进行了测试。现有车轮的开发人员已经遇到了重塑者甚至无法想象的边缘情况和困难。

#3 楼

通常，如果我想要的功能或与其近似的功能存在于我使用的语言的标准库中，则避免重新发明轮子。

但是，如果我必须合并第三方库，则需要根据库的广泛使用和尊敬来做出判断。我的意思是，我们是在谈论Boost还是Bob的Kick-ass字符串解析工具1.0？

即使该库在整个行业中通常是众所周知的和备受尊敬的，它仍然是第三方依赖项。程序员通常将重点放在代码重用的优点上，同时常常掩盖依赖的危险。从长远来看，具有太多第三方依赖项的项目很可能会崩溃，因为它慢慢演变为维护的噩梦。

因此，利用现有代码是好的-但依赖关系是不好的。不幸的是，这两个语句彼此矛盾，所以诀窍是试图找到适当的平衡。因此，您需要确定可接受的依赖关系。就像我说的那样，该语言的标准库中的任何内容很可能都是可接受的依赖关系。从那里继续前进，在整个行业中广受好评的库也通常是可以接受的（例如Boost for C ++或jQuery for Javascript）-但是它们仍然不如标准库理想，因为它们确实比标准库更不稳定。

对于相对未知的库（例如SourceForge上的最新上传文件），这些库具有极大的风险，除非您对源代码足够熟悉，否则我通常建议在生产代码中避免使用这些库自己维护它们。

因此，这实际上是一种平衡行为。但问题是，只是盲目地说“代码重用好！重塑轮子不好！”是一种危险的态度。必须权衡利用第三方代码的好处与引入依赖项的缺点。

#4 楼

方轮必须重新发明。吸吮的努力必须重复。也许缺少该方法的文档，并且另一个程序员觉得只编写自己的方法而不是尝试解决问题要容易得多。也许该方法的调用方式很笨拙，不适合编程语言的习惯用法。

只要问他缺点是什么。

#5 楼

如果人们不重新发明轮子，那么世界将充满。.

这里是我工作场所的对话：

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

有两种选择：要么重新发明轮子或使用Colorama。这是每个选项都会导致的结果：
使用Colorama

运行起来可能会更快一些。使用Colorama之前像以前一样愚蠢

重新发明轮子

您了解一些程序如何显示颜色
您了解到特殊字符可用于在任何颜色上着色终端
您可以使用将来可能使用的任何编程语言进行着色
您的项目不太可能崩溃

如您所见，这完全取决于上下文。重塑方向盘是我经常做的事情，因为我希望能够自己思考，而不要依靠别人为我思考。但是，如果您正在按时完成任务，或者尝试执行的任务非常庞大并且已经存在，那么最好使用那里的内容。
更新（经过几年的经验）
我更新我的回答是，经过多年从事多个项目的研究，我的看法略有改变。也要回答一些意见。
首先，重新发明轮子的意思是，实际上已经存在至少第3个第三方库的情况下，为特定功能创建一个库。
什么时候需要重新发明轮子


当您想学习时。


当您确切地知道自己需要什么时，现有的库就会变成太复杂了，以至于无法满足您的需求。


当现有库的开销使您所需的功能过度饱和时。例如。当您只需要在文档中数几个单词时使用NLP。


当您正在寻找功能时，从头开始做起来并不太复杂（例如重建一个全新的操作系统内核）。


当跨平台不是必需的时（如果由第三库提供）。


当然，这一切都取决于上下文。有时第3方库可能无法正确维护，或者只是将其分叉并建立在顶部就更有意义了。

#6 楼

重新发明轮子的一个有用原因是出于学习目的-但我建议您自己动手做。随着更多的罐头解决方案可用，并提供了更多的抽象级别，我们的工作效率将大大提高。我们可以专注于业务问题，而不是一遍又一遍地调整的通用内容。但是，由于这个原因，您可以尝试自己重新实施解决方案，从而提高自己的技能并学到很多东西。只是不一定要用于生产用途。

另一件事-如果担心的是可能会消失的公司对第三方库的依赖，请确保有获取源代码的选项，或者

顺便说一句，如果您选择实现自己的实现，请避免对密码或其他与安全相关的功能执行此操作。为此，可以使用已建立（并经过充分测试）的工具，在当今时代，这种方式太冒险了，以至于无法自己动手。那是永远不值得的，而且我仍然听说有团队这样做的消息令人恐惧。

#7 楼

当然，出于无知和傲慢，一时兴起地重新发明轮子可能是一件坏事，但是恕我直言，摆锤已经摆得太远了。轮毂能够完全满足您的需求，仅此而已，这是一个巨大的优势。

通常，当我看一个现有的轮子时，它要么做得比我需要的要多，遭受内部平台效应的困扰，因此不必要地变得复杂，或者却缺少了我的一些关键功能

此外，使用现有的轮子常常给我的项目增加我不想要的约束。例如：


现有的轮子与我原本希望使用的轮子和语言或编程风格不同。
现有的转轮仅适用于语言的旧版本（例如，Python 2而不是Python 3）。
在效率，灵活性和简单性之间需要权衡的情况下，现有的车轮做出的选择对于我的用例而言不是最理想的。 （众所周知，在这种情况下，我甚至从最初编写自己的库中重新发明了功能。通常是因为当我当前需要在我的特定领域中非常快的东西时，我将该函数的库版本编写为通用且相当有效的。案例。）
现有的轮子有大量的遗留废料，在新代码的情况下完全没有用，但仍然给生活带来了困难（例如，我使用的Java库迫使我使用其糟糕的容器类，因为之前写的泛型等）。
现有车轮对问题进行建模的方式与我的用例所方便的方式完全不同。 （例如，对于我来说，用节点对象和引用表示有向图可能很方便，但是现有的轮子使用邻接矩阵，反之亦然。也许对我来说，按列主顺序排列数据很方便，但是
库增加了一个庞大的，脆弱的依赖关系，这在我想部署我的代码的任何地方都无法启动和运行，而我所需要的只是一个很小的麻烦其功能的子集。另一方面，在这种情况下，有时我只是将想要的功能提取到一个新的较小的库中，或者如果库是开源的并且代码库使此操作非常简单，则仅复制/粘贴。 （我什至使用了我自己写的相对较大的库，而不仅仅是其他人的库。）
现有的轮子试图从某种角度上符合一些对我的用例而言既不方便也不相关的标准。

#8 楼

有两种效率可以匹配，即处理/速度（即执行速度）和几乎可以肯定的效率。这是第一个原因-对于存在现有解决方案的合理复杂性问题，几乎可以肯定的是，研究和实现现有库要比编写自己的库快。

第二个原因是现有库（假设它已经成熟）已经过测试并且被证明可以工作-可能在比开发人员更广泛的场景中使用，并且测试团队将能够编写新编写的例程，而这几乎无需花费任何努力。

第三，更容易获得支持。不仅其他人（无论是谁编写的库/组件）都支持和改进它，而且其他开发人员很可能会熟悉它并能够理解和维护前进的代码，所有这些都将正在进行的工作减至最少。成本。

所有假设都具有功能等效性，通常情况并非如此。通常，库会提供您会发现有用但无法证明内置的功能，而所有这些功能突然都是免费提供的。

有很多理由可以自己动手，主要是在您想做些什么的地方内置函数无法做到这一点，并且无法从中获得真正的好处，或者在可用的选项还不成熟的情况下，但是它们不像许多开发人员想象的那样普遍。
此外，您为什么要花费时间解决已经解决的问题？是的，这是一种学习的好方法，但是您不应该以生产代码的正确解决方案为代价来做到这一点，这正是我所假设的。

#9 楼

重塑车轮是学习车轮工作原理的好方法，但并不是制造汽车的好方法。

#10 楼

我经常使用自己的，因为我在发现现有实例之前就已经构建了它，而且我懒得去查找和替换每个实例。另外，我可能会完全理解自己的方法，而可能不了解现有的方法。最后，由于我不完全了解现有的代码，因此无法验证它是否可以完全执行我现有的代码。

有很多代码需要编写，而我却没有得到很多有时会返回并重新编码，除非会影响生产。

实际上，今天仍在使用的一个ASP Web应用程序具有功能齐全的图表，该图表以表格格式显示数据并允许排序/ editing，但是它不是datagrid。它是几年前我第一次学习asp.net时就建立的，它并不了解数据网格。我有点害怕代码，因为我当时不知道我在做什么，但是它有效，准确，易于修改，不会崩溃，并且用户喜欢它

#11 楼

我个人的经验法则是：

在学习时重新发明轮子是件好事。如果有最后期限，则可能要使用现有的轮子。

#12 楼

我目前为一堆廉价滑板车工作。
在“建造还是购买”之间做出决定时，管理者选择了“建造”，而不是根据经济学做出理性的决定。这意味着我们不用花几千美元来购买一个组件或工具，而是花了很多工夫建立自己的工具。从另一家公司购买车轮的费用超出预算，这笔钱算作管理不善的年终奖金。程序员的时间是免费的，因此不计入年终奖金（还有使程序员因无法按时完成所有工作而叮叮当当的额外好处），因此，重新发明的轮子是随心所欲的。
一家理性的公司，成本与他人购买轮子的收益与自己发明轮子的收益之比，将基于短期和长期成本，以及机会成本，因为一个人在重新发明轮子时无法制作新的小部件而损失的机会成本。每天花在重塑轮子上的每一天都是新的东西。
关于构建与购买的介绍。关于构建与购买的文章。

如果我看到有人显然是在通过重塑轮子构建自己的已内置于语言/框架中的方法。首先，为了论证，让我们假设他们的方法和内置方法一样有效。知道内置方法的开发人员也更喜欢自己的方法。
为什么他应该使用内置方法而不是自己的方法？

内置版本会有很多越来越多的人为此而烦恼-因此发现和修复的错误比您的自制代码所能提供的更多。
最后，当您的本地开发人员离开，而其他人必须维护他编写的代码时，它将被完全重构并替换为框架中的内容。我知道会发生这种情况，因为多年来我的雇主已经将代码移植到了较新的VB版本中（最古老的产品已投放市场约20年），而这就是发生的情况。我办公室里雇佣时间最长的开发商已经在这里工作了17年。

#13 楼

重新发明轮子的问题是，有时没有标准的现成轮子可以满足您的需求。那里有很多优质的轮子，有很多尺寸，颜色，材料和构造方式。但是有些日子，您只需要拥有一个非常轻便的车轮即可，它是绿色阳极氧化铝，而且没人能制造。在这种情况下，您必须自己做。

现在，这并不是说您应该为每个项目制造自己的轮子-大多数事情都可以使用标准零件并且对此做得更好。但是有时候，您会发现标准零件无法正常工作，因此您需要自己制造。

最重要的是知道何时制造自己的零件。在开始设计自己的零件之前，您必须对标准零件可以做什么以及不可以做什么有一个很好的了解。

#14 楼

是否重新发明轮子是一项成本/收益的事情。成本是相当明显的...


重新发明要花很多时间。
花更多的时间来记录你所发明的东西。
您不能雇用已经了解自己发明的人。
重新设计不好的东西太容易了，因为设计不良而导致的问题要付出持续的成本。
新代码意味着新的错误。旧代码通常已经删除了大多数错误，对于您不知道的问题可能有一些细微的变通方法，因此在新设计中无法解决。

最后一个很重要-一篇博客文章在某处警告您倾向于“扔掉旧代码并从头开始”，原因是您不了解的许多旧内容实际上是必不可少的错误修正。有一个关于Netscape IIRC的警告性故事。

优点可能是...


添加现有库所不具备的功能的能力。例如，我有“保持”其迭代器/游标实例的容器。插入和删除不会使迭代器无效。指向向量的迭代器将继续指向相同的项目（而不是相同的索引），而与向量中较早的插入和删除操作无关。您根本无法使用标准C ++容器来做到这一点。
针对您的特定要求并尊重您的优先级的更加专业化的设计（但要注意内部平台效应的趋势）。
完全控制-某些第三方不能决定以某种方式来重新设计API，这意味着您必须重写一半的应用程序。
全面的了解-您已经以这种方式进行了设计，因此希望您完全理解这样做的方式和原因。
EDIT您可以通过选择性地模仿它们来从其他库中学习课程，而不会陷入相同的陷阱。

一件事-使用第三方库可以算是重新发明轮子了。如果您已经拥有自己的古老的，使用良好的，经过良好测试的库，那么在丢弃它以使用第三方库之前，请仔细考虑。从长远来看，这可能是个好主意-但是在您到达那里之前，可能会有大量的工作和很多令人讨厌的惊喜（由于库之间的细微语义差异）。例如，考虑一下我从自己的容器切换到标准库的影响。幼稚的调用代码翻译不会考虑标准库容器不维护其迭代器的事实。我根本无法使用简单的翻译来实现将迭代器保存为“书签”以备后用的情况-我需要一些非平凡的替代方法来指示书签位置。

#15 楼

我最近在博客上写了关于这个话题的想法。总结一下：


构建自己的东西几乎总是邪恶的，特别是如果它的功能内置在语言中，那就尤其如此。但是，如果您要评估的是一个在互联网上发现的不成熟/可维护性/记录不良的框架，而不是编写自己的框架，那将是轻而易举的事。
我认为重新发明轮子是很不错的选择软件反模式的可怕比喻。这意味着原始解决方案永远无法改进。废话所谓的轮子可能会在一夜之间过时，或者其所有者可能会停止维护它。车轮在使用该车轮的每个系统上都有不同的值。因此，通常有可能发明出更好的轮子。

制作自己的框架的一个主要好处是，您不必对别人的错误负责。 （这是Amazon的理念。）这样思考：其中哪个更好地告诉客户？ -


“我们的网站坏了。这是别人的错，我们已经在其创建者那里记录了一个错误。除了等待，我们无能为力。我们将继续您已更新。“

”我们的网站已损坏，我们能够立即对其进行修复。“

#16 楼

如果有一个工作组件可以满足您的需求，那为什么还要花时间编写和调试自己的版本？同样，如果您以前已经编写了实现类似功能的代码，为什么还要重新编写呢？

Joel在Not-invented上写了一篇文章，在这里讲到何时重写代码以及软件不是也没有用。

#17 楼

重新发明轮子可能是学习事物运作方式的好方法-我建议您根据自己的时间为此目的重新发明-但是在编写应用程序时，为什么要重新发明是否有完善的解决方案已经在做同样的事情？

例如，我永远不会从头开始编写JavaScript代码；相反，我将从jQuery开始，并在该框架之上构建我的应用程序。

#18 楼

变得“坏”甚至“邪恶”是相当有说服力的词。

一如既往，有理由选择内置实现而不是个人实现。在过去，C程序可能会在运行时库中遇到错误，因此只需提供自己的实现即可。

这不适用于Java程序，因为JVM的定义非常严格，但是有些算法仍然很难解决。例如，约书亚·布洛赫（Joshua Bloch）描述了Java运行时库中看似简单的二进制搜索算法如何包含一个错误，该错误花了九年的时间才浮出水面：

http://googleresearch.blogspot.com/2006/06 /extra-extra-read-all-about-it-nearly.html

在以后的Java发行版中找到，修复并分发了该文件。

如果使用内置二进制文件搜索通过让Sun进行艰苦的工作来查找，修复和分发此错误修复程序，您节省了时间和金钱。您只需说“您至少需要Java 6 update 10”就可以利用他们的工作。

如果您使用自己的实现（很可能也包含此错误），则首先需要显示该错误本身。鉴于这一特定问题仅在LARGE数据集上显示，它一定会在某处的生产环境中发生，这意味着您至少有一个客户会受到影响，并且很可能在您找到，修复和分发该错误修复程序时损失了真实的钱。

因此，偏爱您自己的实现是完全正确的，但最好是真正做到这一点，因为与利用他人的工作相比，这样做必然会更加昂贵。

#19 楼

关于“重塑方向盘”的争论通常是在选择使用图书馆的错误上下文中使用的，但这几乎不是类似的事情。
假设我正在评估一个“ forms-plus”图书馆，该图书馆最近才流行起来，并且对您有所帮助处理表格。它具有一个漂亮的目标页面，现代酷炫的图形以及周围的邪教（哎呀，我的意思是“社区”），他发誓它如何使制表再次变得出色。但是“ forms-plus”是“ forms”之上的抽象。 “形式”是可能的，但处理起来很繁琐，因此使其变得更容易的抽象变得流行。
新的抽象一直在出现。很难将它们与车轮进行比较。它更像是一台新的控制设备和新的手册，可用于您需要运行的任何非常复杂的设备。
根据个人经验，人们对这种新设备“ forms-plus”的评价会有所不同。如果我以前从未构建过表单，那么“ forms-plus”将非常引人注目，因为它更容易上手。不利的一面是，如果“ forms-plus”被证明是一个泄漏的抽象，我仍然仍然需要学习“ forms”。如果构建的表单没有“ forms-plus”，那么我将需要考虑学习新工具的时间。好处是我已经知道“形式”，因此我不怕它之上的抽象。对于新手来说，短期收益通常会更大，因为如果没有改进，那么就不会有新的图书馆。长期利益将在抽象质量，采用率和其他答案中已经讨论的其他因素上有很大差异。
在仔细评估了使用新的抽象“ forms-plus”与使用裸露的“ forms”的成本和收益之后，我做出了决定。这个决定很大程度上取决于我的个人经验，不同的人会做出不同的决定。我可能选择使用准系统“表格”。也许在以后的时间形式中，加号会在其背后获得更多动力，并成为事实上的标准。也许随着时间的流逝，我自己的实现可能会变得繁琐，并开始涵盖许多form-plus正在做的事情。后来的人们会批评我太热衷于重新发明轮子，而我应该使用现有的库。但是，当我不得不对“ forms-plus”做出决定时，也有可能是“ forms-plus”的其他多种选择，到现在大多数都是无效的项目，而且可能我没有选择错误就获得了收益。一个。
最后，选择正确的工具是一个复杂的决定，而“重塑车轮”并不是一个很有帮助的观点。

#20 楼

尽管对某些人而言是令人反感的，但我经常发现该术语在被任何形式的工程师使用或提及创建或设计事物的主题时都不明智。实际上，在考虑到当今快速发展的世界中进行创新的压力时，我不禁将其视为不诚实的。重复自己（或忽略适当的，已有的解决方案）从来都不是明智的选择，但是，确实有一个原因，为什么我们还不都盯着充满绿色字母的黑屏。

我理解“如果它不会破产，请解决它”，尽管我想这样的话对某些人来说可能是无知的。然而，随着当前为太空旅行，赛车，运输等需求重新发明轮子的努力，“不要重新发明轮子”也很无知，而且听起来还不那么聪明。

我的背景包括领导多个项目，我不得不与许多实习生和其他形式的绿色开发人员合作，而且我不得不处理许多天真的问题，有些问题被称为“愚蠢的”，并且还不得不将人们转移到他们的任务范围之外。但是，我永远不会阻止创新或创造力，并且看到伟大的事物来自“重新发明轮子”。

我对这个问题的实际回答：只有两种情况可以使我们重新发明滚轮是坏事：


如果不是真的需要
如果有其他人这样做的话

编辑：
我可以通过开车经过的不赞成票看到我一定得罪了一些。我想补充的一件事是，这句话一直是我的主要观点。我了解我的两分钱听起来可能有些古怪，但我无意进行古怪，引起火灾或冒犯。

#21 楼

也许它效率一样高，但功能强大吗？我认为使用库来滚动自己的库的最令人信服的理由是，该框架有太多人在使用它，因此他们可以快速找到并修复错误。内部开发的库虽然可以提供同样（或更多）的功能，但无法与拥有数百万用户的库竞争以在几乎每个用例中提供测试。您只是无法在内部击败这种测试。

#22 楼

好吧，他自己的方法像框架一样高效的情况将很少见，因为大多数框架仍然存在错误，并且没有框架可以为您提供即用的解决方案。大多数无法思考的程序员永远不会尝试在框架级别上编写任何东西。他们只会在Google上搜索现成的解决方案。任何明智的程序员都将首先查看是否有一个免费的框架，该框架具有他需要的功能，然后，如果没有，请自己编写解决方案。有时很难解释当前的项目情况，而开发人员是最好的判断者。

重塑方向盘还不错，这是懒惰的人避免努力工作的说法。即使是框架作家也确实在重塑。整个.Net框架被重新发明以完成COM提供的功能。

#23 楼

在某些情况下，增加您的自主权可能是个好主意：
想象一下三个不同的团队使用一个公共库，该库需要进行很多更改并可能具有不同的需求。这将迫使三个团队通过会议协调他们的开发和部署，并了解彼此的需求和代码。一个团队的变更可能会破坏另一团队的代码。这可能会降低敏捷性。
另一个示例是使用第三方库。您可能会发现需要进行更改。即使您愿意支付支持费用或为开放源代码做出贡献，您也可能会发现下一个版本可能在几个月内无法准备就绪。开发人员甚至可能认为他们不想涵盖您的用例。您可以结束开源git的分支。
这与上下文密切相关：

该库有多大，稳定，有据可查或受支持？
有多少功能？您现在和将来都需要吗？
需要自定义修改的可能性有多大？
团队中的任何人都知道如何使用它吗？

但是请不要重新发明春天。

#24 楼

如果引入某个第三方框架，则由您负责该框架，必须确保它没有安全性问题，并且必须跟上新版本。今天可能是一天的工作，但是将来您将不得不花费很多时间。更糟的是，如果进行更改，则必须一次又一次地合并到新版本中。
问自己：您是在重新发明轮子吗？还是只是在重新发明如何煮一杯咖啡？您是否只是在写几行代码，每个体面的开发人员都可以轻松编写这些代码？确保新框架确实值得，因为您将长期付出代价。

#25 楼

我写了一篇关于此的文章-http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

-发明确实很棒-尽管冗长而乏味。我想说的是，如果您不完全了解要使用的编程模型，请自己编写（如果您有时间和精力的话）。这将告诉您这些编程模型的确切含义，最终您将成为更好的程序员。当然，如果您正在为客户工作并且只需要快速起步，那么您可能只想进行一些研究并找到适合您的软件。

#26 楼

车轮有很多不同的类型
自行车上不能装自行车车轮。购物车轮完全不足以运输火箭。水车不适用于办公椅。
市场上可能没有一个水轮适合您要做的事情。那是您发明新产品的时候。将LEGO车轮安装在飞机上是确保杀死乘客的好方法。
这种“永远不要重新发明车轮”的文化是导致左垫惨败的原因。它使我们走上了React和虚拟DOM的道路，而不是直接使用画布进行自定义渲染，而是采用了更简单，更不易出错的方法。这本质上就是游戏的功能，以及为什么浏览器难以流畅滚动文本时却能以60+ FPS的速度运行。
使用正确的轮子进行工作。如果那意味着重新发明它，请这样做。