「車輪の再発明」とは反対のアンチパターンの名前は何ですか？
" Reinvent the wheel "アンチパターンは非常に一般的なものです。既製のソリューションを使用する代わりに、独自のアンチパターンを最初から作成します。コードベースは、同じことを行うがわずかにわずかに異なるインターフェイスが不必要に大きくなり、すぐに利用できる関数を記述（およびデバッグ）するために時間を浪費しています。私たちは皆これを知っています。
しかし、スペクトルの反対側に何かがあります。 2行のコードである独自の関数を作成する代わりに、フレームワーク/ API /ライブラリをインポートし、インスタンス化し、設定し、コンテキストをデータ型に変換し、フレームワークで受け入れられるようにして、必要な機能を実行する単一の関数を呼び出します。ギガバイトの抽象化レイヤーの下にある2つのビジネスロジック。そして、ライブラリを最新の状態に保ち、ビルドの依存関係を管理し、ライセンスを同期させておく必要があります。そのインスタンス化のコードは、単に「ホイールを再発明」した場合よりも10倍長く複雑です。
理由はさまざまです。コストに関係なく「ホイールの再発明」に厳密に反対する経営陣、要件とのわずかな重複にもかかわらず、誰かが好む技術を押し進めている、以前はシステムの主要なモジュールの役割が減少している、または拡張と拡大の期待到着しないフレームワークの使用、または単に「重み」を誤解しているインポート、インクルード、ロードの2つの命令が「舞台裏」で実行されます。
この種のアンチパターンの一般的な名前はありますか？
（それが正しいか間違っているか、またはそれが本当のアンチパターンまたは何か意見ベースである場合、私はディスカッションを開始しようとはしていません、これは単純で簡単で客観的な命名法の質問です。）
編集：提案された「重複」は、外部システムとは別に、独自のコードをオーバーエンジニアリングして「すべての準備ができている」ようにすることを話します。このことは特定の場合にはそれに起因する可能性がありますが、一般的には「ホイールの再発明への嫌悪」から発生します。私たちの問題の「既製」の解決策が存在する場合、それがどれほどうまくいかなくても、どんなコストでそれを使っても私たちはそれを使用します。コードの複製よりも新しい依存関係の作成を独断的に支持し、新しいコードの作成および保守のコストと比較した場合、これらの依存関係の統合および保守のコストを完全に無視します。
いいえ。あなたが説明しているものをカバーする一般的に使用されるアンチパターン名はありません。
ゴールデンハンマー
ゴールデンハンマーは、ファンシーであるという理由だけで選択されたツールです。目的のタスクを実行するのに費用対効果も効率もよくありません。
ソース： xkcd 801
（反対投票にもかかわらず、私はこの回答を支持します。これは、意味論的にホイールを再発明することの正反対ではないかもしれませんが、質問で言及されたすべての例に適合します）
Robert Martinは、このアンチパターンの最も明白な否定的な結果を指すために " Framework Bound "という用語を使用しています。パターン自体には一般的な名前はないと思うので、ほとんどの場合、この結果への参照で十分です。
" Invented Here "に関するこのウィキペディアのページでは、少し異なる状況について説明していますが、最終結果は非常に似ています。同等の機能が見つかる場合に、独自のコードを作成することに対するチームの嫌悪感について説明します。
名前が少し誤解を招くかもしれないと私は主張します。反対の文脈で置くと感覚が得られます Not Invented Here これは、ホイールを再発明することとほぼ同じです。
" Buy Versus Build "と " Invented Here "は、社内で開発することに対するバイアスのアンチパターン名として聞いたことがあります。そうする。 （そして、「購入するかビルドするか」というフレーズは、実行可能な選択肢の選択肢を示すことになっていますが、誰かが「購入する」が正しい選択であると信じている場合、それは通常言及されています。 ）
蚊を殺すために大砲を使用しないでください
孔子
AKAオーバーキル
Bloatは広義の用語ですが、ユーザーが説明した内容を含めることができます。私たちのソフトウェアは、必要なすべての追加の変換と抽象化のために過度に複雑（肥大化）になり、複雑さと依存性の両方がパフォーマンスの低下/効率の低下とリソース消費（ディスク、帯域幅）の増加につながります。
必要に応じて、肥大化した依存関係のような用語で明確にすることができます。
完全に類似しているとは思いませんが、オーバーデザインまたはオーバーエンジニアリングが最も近くなります
少なくとも、私はあなたが説明しているのと同じような何かに遭遇したときに本当にが起こっていたのだと主張します。
独自のコードを作成する代わりにライブラリを使用して実装する同じ機能が害を及ぼすことはほとんどありません。
仮説の例でも、「2行のコード」を置き換えるためにライブラリを使用する必要はないかもしれませんが、それが実際に2行のコードと同じことを行うことを目的としたライブラリである場合、多くの悲しみを引き起こすことはありません。 。
簡単なことをするためのライブラリも簡単になります。それはあなたの質問が意味する頭痛を与える可能性は低いです。
複雑なライブラリを使用して単純なことを行うと、必要な機能を実装する以上のことを試みていることを意味します。
不要な機能を組み込んだり、二度と来ない未来に備えるなど。
ここでの問題は、実際に車輪自体を再発明することに失敗したことではありません。
ハンマーを使ってナッツを割るはかなり近いと思います。これは可能なことですが、1つのナットをそのようにクラックするには、望ましくない副作用が多数発生することなく、非常に多くの作業が必要です。 （そして、クラックするナッツの袋全体があります...）
また、この用語には専門用語を計算しないという利点もあります。そのため、何も知らない人に手がかりを与えるのに非常に役立ちます。
ちなみに、依存性地獄で描くには違いがあります。単純で明確で使いやすいインターフェースを作成するカプセル化の中にすべての複雑さをすでにラップしていて、CPUサイクルまたはメモリ使用量のペナルティが過度ではなく、カプセル化されたコードの将来の変更が提供される可能性が低い場合必要な場合、それを使用することに対する残りの議論は、それが引き起こしている可能性がある依存関係の地獄です。
ホイールを再発明していない場合は、ベンダーまたはサードパーティから提供されている既存のホイールセットを使用している可能性があります。
これがアンチパターンである場合は、通常、ベンダーロックインと呼ばれます。
ジョブセキュリティ？
あなたは物事を同期させるなどのあらゆる努力に言及しています。他の人のコードを自分で書くよりも管理したい人もいます。特にマネージャー。