通常，您必须满足“不要重新发明轮子”的建议。 有时明显地被忽视和自我肯定，有时表面上是好的建议。 但是，即使它被认为是明智的建议，但在许多情况下，它仅表明说话者的无能。
该短语的嵌套用途是使您免于无用的工作，避免使用现成的解决方案来完成任务，并且从外部观察者的角度来看，它的确看起来很合理。
但是同时，不仅缺少软件开发而且还解决任何问题的关键因素都被 遗漏了 ： 在更改设置任务的环境时，解决方案也会更改 。
忽视这一原理与承认自己无力解决所应用的问题一样。
考虑几种情况。
来源
API之上的API
指控循环的一种常见情况是某些服务的自写API包装器，该服务的实现已可用。
我的一个案例。
有必要实现从Facebook向我们的服务上传数据。 主流语言和Facebook本身的库在2分钟内被谷歌搜索到。
库文档与当前程序界面不符 ，每次操作都包裹了许多不必要的动作。 事实证明图书馆的质量很差 。
结果：使用1.5小时后，甚至无法登录。
一位同事实施了自己的Facebook网络API包装器。 总共花了他一个小时的时间在服务端创建包装器和相关功能。 接下来的几天，他回答了“为什么要在这里骑车”这个问题。
这在具有大型社区的主流语言中尤其明显：以“为人类”和“以简单的方式”为口号，在另一个API上发布API包装器的趋势是不健康的。 一旦包装的接口更新，此类包装器就会过时，并且作者放弃了此类“项目”，从而使使用它们的代码无法使用。
一个好问题 ： 什么？每次手动编写此类包装器？
答： 对于大型包装器， 一种 更强大的解决方案是使用解释规范的代码生成器。
控制代码库，拒绝回答他人的错误
在计算机游戏开发中的想要的圈子中，此短语适用于任何敢于实现其引擎的人。 “为什么要重新发明轮子？团结一致！” 。 或游戏制作者，或者，上帝禁止，折叠。
dviglo \构造函数似乎提供了所有必要的开发工具，其中许多是跨平台的，通常可以简化生活。
这里的上下文应该如何更改，以便有必要制造自己的引擎？
至少，这是对代码库和引擎功能的控制 （例如，在许多控制器模型上，游戏制造商始终存在漏洞，而修复该漏洞可能会成问题）。 也就是说，有必要减少遇到“外来错误”的可能性，这种可能性是不可能或很难自行修复的。
这在没有图形和/或物理铃铛和口哨声的游戏中尤为明显-老套，而条件引擎本身并没有那么多。
此外，如果从引擎/构造函数使用一小部分功能 ， 则无需增加代码库的总量 ，并且仍然需要独立添加必要的工具，同时控制其与引擎一起工作的正确性。
例如，基于这样的前提， 汤米·雷芬斯（Tommy Refenes）为《超级肉仔》（Super Meat Boy）编写了自己的引擎 。
有人会反对： “但是在仓库\其他仓库中，有大量的预设\工具\扩展！” 。
是的，它很棒，并且提出了两个要点，但是在拥有大量活跃用户群的引擎中，可以观察到上一节所述的“年轻时”效果。 没有上下文和特定任务，就不能毫无疑问地断言 ， 商店中大量的用户扩展将发挥作用。
虚构的身份。 紧紧抓住任务。
有时，提出问题后，事实证明，想到的现有解决方案不适合。 由于其“脂肪含量”或对该任务的关键条件之一的不满意（ 是的，有几个条件 ）。
很好的例子：CluNet。
Cluster在他的文章中相当完整地描述了他在开发智能家居协议时做出决定的原因。 这个例子非常有启发性，并且描述得很好，我建议您自己拆解它。
结论
在寻找问题的解决方案时， 必须考虑上下文和所有给定条件 。
即使在简单的情况下，上下文的小细节也会使解决方案倒置， 解决应用问题的技能很大程度上取决于查看和评估初始前提的能力 。
那么，“不要重新发明轮子”这句话是否表示顾问无法解决问题？ 如果顾问在几分钟后犹豫不决地提到自行车，很可能是这样。
或者，按照机长的概括：
决定前要三思。
说话前先思考。
和一般-思考。