「車輪の再発明」アンチパターンは非常に一般的なものです-すぐに使えるソリューションを使用する代わりに、独自にゼロから作成してください。コードベースは不必要に成長し、同じことをするわずかに異なるインターフェースがわずかに異なりますが、わずかに異なりますが、すぐに利用できる関数を書く（そしてデバッグする）時間は無駄になります。私たちは皆これを知っています。
しかし、スペクトルの反対側に何かがあります。2行のコードである独自の関数を作成する代わりに、フレームワーク/ API /ライブラリをインポートし、インスタンス化し、構成し、フレームワークで受け入れられるようにコンテキストをデータ型に変換し、必要なことを正確に行う1つの関数を呼び出します。ギガバイトの抽象化レイヤーの下の2行のビジネスロジック。そして、ライブラリを最新の状態に保ち、ビルドの依存関係を管理し、ライセンスの同期を維持する必要があります。また、インスタンス化のコードは、「車輪を再発明」した場合よりも10倍長く複雑です。
理由はさまざまです：コストに関係なく「車輪の再発明」に厳密に反対する経営陣、要件とわずかに重複しているにも関わらず、彼らの好みの技術を押している人まだ到着していないフレームワークの使用、またはいくつかのインポート/インクルード/ロード命令が「舞台裏」で伝える「重み」を誤解している。
この種のアンチパターンに共通の名前はありますか？
（それが正しいか間違っているか、それが本当のアンチパターンまたは意見に基づいたものである場合、私は議論を始めようとはしていません。これは単純で客観的な命名法の質問です。）
編集：提案された「重複」は、外部システムとは完全に離れて、「すべての準備を整える」ために独自のコードをオーバーエンジニアリングすることについて語っています。このことはある場合にはそれから生じるかもしれませんが、一般的には「車輪の再発明への嫌悪感」に由来します。問題に対する「既製の」解決策が存在する場合、それがどの程度適合しておらず、どのような費用がかかっても、それを使用します。新しいコードの作成とメンテナンスのコストと比較した場合、これらの依存関係の統合とメンテナンスのコストを完全に無視して、コードの重複よりも新しい依存関係の作成を独断的に支持します。