車輪の再発明は本当に悪いことですか？

プログラミングにおけるその一般的な知識は車輪の再発明は悪いかであることを悪。

しかし、それはなぜですか？

私はそれが良いことを示唆していません。私はそれが間違っていると信じています。しかし、誰かが何か間違ったことをしている場合（プログラミングの観点から）なぜ間違っているのかを説明し、できない場合は、それが本当に間違っているかどうかを自問するべきだという記事を一度読みました。

それは私にこの質問につながります：

誰かが、言語/フレームワークに既に組み込まれている独自のメソッドを構築することにより、明らかに車輪を再発明しているのを見た場合。まず、引数のために、メソッドが組み込みメソッドと同じくらい効率的であると仮定しましょう。また、組み込みメソッドに気付いている開発者は、独自のメソッドを好みます。

なぜ彼は自分のビルトインを使用する必要があるのですか？

私がかつてStackOverflowに投稿したように、一般的な考えに反して、車輪の再発明はしばしば非常に良い選択です。主な利点は、ソフトウェアを完全に制御できることです。これは多くの場合不可欠です。完全な議論については、元の投稿を参照してください。

依存する..

すべてと同様に、そのコンテキストについて：

次の場合に適しています：

• フレームワークまたはライブラリが重すぎるため、必要な機能は限られています。要件に合った独自の非常に軽量なバージョンを展開することは、より良いアプローチです。
• 複雑なものを理解して学習したいときは、自分で転がすのが理にかなっています。
• 提供するものとは異なるものがあり、他の実装にはないものがあります。新しいひねりや新機能などがあります。

悪いのは：

• 機能は既に存在し、安定しており、よく知られている（人気のある）ことが知られています。
• あなたのバージョンは何も新しく追加しません。
• バージョンにバグや制約があります（たとえば、バージョンがスレッドセーフではありません）。
• バージョンに機能がありません。
• お使いのバージョンには、より悪いドキュメントがあります。
• お使いのバージョンには、置き換えられるものと比較した単体テストがありません。

開発者が「自分の方法を好むために」車輪を故意に再発明するケースはかなりまれだと思います。ほとんどは無知から、時には頑固さから行われます。

それはすべて悪いですか？はい。どうして？既存のホイールは時間の経過とともに作成された可能性が高く、多くの状況で、さまざまな種類のデータに対して既にテストされているためです。既存のホイールの開発者は、再発明者がまだ想像することさえできないエッジケースと困難にすでに直面しています。

四角い車輪を再発明する必要があります。ひどい努力を繰り返す必要があります。メソッドのドキュメントが不足している可能性があり、他のプログラマーは、それを理解しようとするのではなく、自分で書くだけの方が簡単だと感じています。メソッドの呼び出し方が面倒で、プログラミング言語のイディオムに合わないかもしれません。

欠乏症とは何かを彼に尋ねてください。

一般に、使用する言語の標準ライブラリに、必要な機能またはそれに近いものが存在する場合、ホイールの再発明は避けます。

ただし、サードパーティのライブラリを組み込む必要がある場合、そのライブラリがどれだけ広く使用され評価されているかに応じて判断する必要があります。つまり、BoostのKick-ass String-Parsing Tools 1.0のことですか？

ライブラリが業界全体で一般によく知られ、高く評価されている場合でも、サードパーティの依存関係です。プログラマーは一般に、コードの再利用の美徳を非常に重視し、依存関係の危険性をしばしば強調します。サードパーティの依存関係が多すぎるプロジェクトは、メンテナンスの悪夢にゆっくりと発展するため、長期的にはバラバラになる可能性があります。

したがって、既存のコードを活用するのは良いことですが、依存関係は悪いです。残念ながら、これらの2つのステートメントは相反するため、適切なバランスを見つけようとしています。そのため、受け入れ可能な依存関係を識別する必要があります。私が言ったように、言語の標準ライブラリにあるものはすべて、おそらく受け入れられる依存関係です。そこから上に移動すると、非常に業界全体で考えているライブラリはまた、（C ++、またはJavaScriptのためのjQueryのためのブーストのような）一般的に許容されている-しかし、彼らはまだ少なく、彼らはので、標準ライブラリより望ましいん標準化されたライブラリよりも不安定になる傾向があり。

比較的未知のライブラリ（たとえば、SourceForgeでの最新のアップロード）については、これらは非常に危険な依存関係です。一般的に、ソースコードに精通していない限り、実稼働コードではこれらを避けることをお勧めします。

だからそれは本当にバランスのとれた行為です。しかし、ポイントは、「コードの再利用は良い！ホイールの再発明は悪い！」と盲目的に言っているだけです。危険な態度です。サードパーティのコードを活用する利点は、依存関係を導入することの欠点と比較検討する必要があります。

人々が車輪を再発明しなければ、世界はこれらで満たされるでしょう。

ここに私の職場からの対話があります：

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

2つのオプションがあります：ホイールを再発明するか、Coloramaを使用します。各オプションの結果は次のとおりです。

コロラマの使用

• 実行するのに少し速いかもしれません
• 些細なことにサードパーティの依存関係を追加する
• コロラマを使用する前と同じくらい愚かであり続ける

車輪の再発明

• 一部のプログラムがどのように色を表示できるかを理解している
• どの端末でも特殊文字を使用して色付けできることを学びます
• 将来使用する可能性のあるプログラミング言語で色を付けることができます
• あなたのプロジェクトは壊れにくい

ご覧のとおり、すべてはコンテキスト次第です。車輪を再発明することは私ができることであり、自分のために考えたいと思っているので、他の人が私のために考えていることに依存するのではないので、私は非常に頻繁に行います。ただし、期限内に実行している場合、または実装しようとしているものが巨大で既に存在している場合は、そこにあるものを使用する方が良いでしょう。

車輪を再発明するための有用な理由の1つは、学習を目的としていますが、自分の時間に行うことをお勧めします。より多くの事前に定義されたソリューションが利用可能になり、より多くの抽象化レベルが提供されるようになると、私たちはより生産的になります。何度も調整されてきた一般的な問題ではなく、ビジネスの問題に集中できます。しかし、そのため、自分でソリューションを再実装することで、スキルを磨き、多くを学ぶことができます。必ずしも本番用ではありません。

もう1つ-懸念が消える可能性のある会社のサードパーティライブラリへの依存関係である場合、ソースコードを取得するオプションがあることを確認するか、少なくともいくつかの他の選択肢があります。

ところで、独自の実装を選択した場合は、暗号化やその他のセキュリティ関連機能のためにこれを実行しないでください。確立された（そして完全にテストされた）ツールがそのために利用可能であり、この日と時代では、あなた自身のものをロールバックするのはあまりにも危険です。それはそれだけの価値はありませんし、チームがこれをしていると聞いているのは怖いです。

2種類の効率性があります。処理/速度（実行速度）と一致する場合と、開発速度がほぼ確実に一致しない場合です。それが最初の理由です- 既存のソリューションが利用可能な合理的な複雑さの問題の場合、独自のコードを作成するよりも既存のライブラリを調査して実装する方がほぼ確実に高速になります。

2番目の理由は、既存のライブラリ（成熟していると仮定）がテストされ、動作することが証明されていることです。おそらく、開発者やテストチームよりもはるかに幅広いシナリオで、新しく書かれたルーチンを実行できます。労力ゼロ。

第三に、サポートがずっと簡単です。他の誰かがそれをサポートおよび改善するだけでなく（ライブラリ/コンポーネントを作成した人）、他の開発者がそれを熟知し、今後のコードを理解および維持できる可能性がはるかに高くなります。コスト。

そして、それは機能的な同等性を前提としていますが、通常はそうではありません。多くの場合、ライブラリは便利な機能を提供しますが、組み込みを正当化することはできません。そのすべてが突然無料で利用可能になります。

自分でロールバックする理由があります-主に組み込み関数ではできないことをしたい場合、そうすることで得られる真の利点がある場合、またはすぐに利用可能なオプションが成熟していない場合-しかし、多くの開発者があなたに信じさせるほど一般的ではありません。

それに、なぜ既に解決された問題を解決するのに時間をかけたいのでしょうか？はい、それは学ぶための素晴らしい方法ですが、私たちが話していると仮定している本番コードの適切なソリューションを犠牲にしてそれを行うべきではありません。

もちろん、無知と慢から抜け出すために、気まぐれに車輪を再発明するのは悪いことですが、振り子があまりにも遠く振れています。あなたが望むものを正確に実行し、それ以上何もしないホイールを持つことには、大きな利点があります。

多くの場合、既存のホイールを見ると、必要以上に機能し、内部プラットフォーム効果に苦しんでいるため、不必要に複雑であるか、必要な重要な機能が欠落しており、それが難しい既にあるものの上に実装します。

さらに、既存のホイールを使用すると、プロジェクトに不要な制約が追加されることがよくあります。例えば：

• 既存のホイールには、他の方法で使用したい場合とは異なる言語やプログラミングスタイルが必要です。
• 既存のホイールは、言語のレガシーバージョン（たとえば、Python 3ではなくPython 2）でのみ機能します。
• 効率、柔軟性、シンプルさの間でトレードオフがある場合、既存のホイールは、ユースケースに最適ではない選択を行います。（私は、これらのケースで最初に自分で書いたライブラリから機能を再発明することで知られています。通常、それは私が現在特定の非常に高速なものを必要とするときに、関数のライブラリバージョンを汎用的で合理的に効率的に書くためです場合。）
• 既存のホイールには、新しいコードの場合にはまったく役に立たないが、それでも生活を難しくする多くのレガシークラフトがあります（たとえば、ジェネリックなどの前に記述されたため、そのくだらないコンテナークラスを使用せざるを得ないJavaライブラリー） 。
• 既存のホイールが問題をモデル化する方法は、私のユースケースにとって便利な方法とはまったく異なります。（たとえば、ノードオブジェクトと参照で表される有向グラフがあると便利かもしれませんが、既存のホイールは隣接行列またはその逆を使用します。既存のホイールは、行メジャーまたはその逆を主張します。）
• このライブラリは、必要なのがその機能の小さなサブセットである場合、コードを展開したいすべての場所で立ち上げて実行するための大きな手間となる巨大で脆弱な依存関係を追加します。一方、この場合、私は時々、必要な機能を新しい小さなライブラリに抽出するか、ライブラリがオープンソースであり、コードベースがこれを十分に簡単にする場合にコピー/貼り付けするだけです。（他の人だけでなく、自分で書いた比較的大きなライブラリでもこれを実行しました。）
• 既存のホイールは、不便であり、私のユースケースにとっては無関係な何らかの標準に忠実に準拠しようとします。

多くの場合、既存のものを発見する前に構築したため、独自のものを使用します。すべてのインスタンスを見つけて置き換えるのは面倒です。また、私は自分の方法を完全に理解していますが、既存の方法を理解していないかもしれません。そして最後に、私は既存のものを完全に理解していないので、現在のものが完全に機能することを完全に確認することはできません。

コーディングすることはたくさんありますが、生産に影響を与えない限り、戻って何かを再コーディングする時間はあまりありません。

実際、現在も使用されている1つのasp Webアプリには、データを表形式で表示し、並べ替え/編集を可能にする完全に機能するグラフがありますが、データグリッドではありません。asp.netを初めて学んだとき、データグリッドを知らなかった数年前に作成されました。当時私が何をしていたのかわからないので、コードが少し怖いですが、動作し、正確で、修正しやすく、クラッシュせず、ユーザーはそれを気に入っています

ホイールの再発明は、ホイールの仕組みを学ぶのに最適な方法ですが、車を作るのに適した方法ではありません。

私は現在たくさんの安いスケート靴で働いています。

経済学に基づいて合理的な決定を下すのではなく、「構築または購入」の間に決定が下される場合、マネージャーは「構築」を選択しました。これは、コンポーネントまたはツールに数千ドルを支払う代わりに、私たちが自分自身を構築するのに人月を費やすことを意味します。別の会社からホイールを購入すると、予算から出てくるお金がかかります。これは、誤った年末のボーナスにカウントされます。プログラマの時間は自由であるため（ 『時間に』すべては終らないため、プログラマをdingingの追加の利点と）、年末賞与に対してカウントされませんので衣替えホイールはフリーホイールです。

合理的な会社では、他の人が作ったホイールを購入することと自分のホイールを再発明することのコスト対利益は、短期および長期のコスト、および新しいウィジェットを作成できないために失われる機会コストに基づいています車輪の再発明。車輪の再発明に費やす毎日は、新しいものを書くことができない別の日です。

ビルドと購入に関するプレゼンテーション。
ビルドと購入に関する記事。

誰かが、言語/フレームワークに既に組み込まれている独自のメソッドを構築することにより、明らかに車輪を再発明しているのを見た場合。まず、引数のために、メソッドが組み込みメソッドと同じくらい効率的であると仮定しましょう。また、組み込みメソッドに気付いている開発者は、独自のメソッドを好みます。

なぜ彼は自分のビルトインを使用する必要があるのですか？

ビルトインバージョンでは、多くの人がそれを叩き出していました。したがって、自作のコードよりも多くのバグを見つけて修正できます。

最後に、ローカル開発者が去り、他の誰かが彼が書いたコードを保守しなければならない場合、それは完全にリファクタリングされ、フレームワーク内のものに置き換えられます。私の現在の雇用主が長年にわたって新しいバージョンのVBに移行したコードを持っているためにこれが起こることを知っています（最も古い製品は約20年間市場に出回っています）。私のオフィスで最も長く働いている開発者はここに17年います。

車輪の再発明に関することは、必要なことを行う標準的な既製の車輪がない場合があることです。たくさんの良いホイールがあり、サイズ、色、素材、構築方法がたくさんあります。しかし、時には、陽極酸化処理された緑色のアルミ製の軽量なホイールが必要な場合もあります。その場合、自分で作らなければなりません。

今では、すべてのプロジェクトで独自のホイールを作成する必要があると言っているわけではありません-ほとんどのものは標準部品を使用し、より良いものにすることができます。しかし、ときどき、標準部品が機能しないことがわかるため、独自の部品を作成します。

最も重要なことは、いつ自分で作るかを知ることです。独自の設計を開始する前に、標準部品でできることとできないことをよく理解する必要があります。

車輪を再発明するかどうかは、コスト/利益の問題です。コストはかなり明白です...

• 再発明を行うには多くの時間がかかります。
• 発明したものを文書化するにはさらに時間がかかります。
• あなたが発明したものをすでに理解している人を雇うことはできません。
• 何かをひどく再発明するのは非常に簡単で、ひどいデザインによって引き起こされた問題に継続的なコストがかかります。
• 新しいコードは新しいバグを意味します。通常、古いコードではほとんどのバグが既に削除されており、気付いていない問題に対する微妙な回避策があるため、新しいデザインでは回避できません。

最後は重要です-あなたが理解していない古いクラフの多くは実際に不可欠なバグ修正であるという理由で、「古いコードを捨ててゼロから始める」傾向について警告するブログ投稿がどこかにあります。Netscape、IIRCについての警告物語があります。

利点は...

• 既存のライブラリにはない機能を追加する機能。たとえば、イテレータ/カーソルインスタンスを「維持」するコンテナがあります。挿入および削除は、イテレーターを無効にしません。ベクターを指すイテレーターは、ベクター内の以前の挿入や削除に関係なく、同じアイテム（同じインデックスではない）を指し続けます。標準のC ++コンテナでは、これを行うことはできません。
• 特定の要件をターゲットとし、優先順位を尊重する、より専門的な設計（ただし、内部プラットフォーム効果の傾向に注意してください）。
• 完全な制御-一部のサードパーティは、アプリケーションの半分を書き直す必要があるという方法でAPIを再設計することを決定できません。
• 完全な理解-あなたはそれをそのように設計したので、あなたはそれをどのように、そしてなぜ行ったかを完全に理解することを望みます。
• 編集どのように模倣するかを選択することにより、同じトラップに巻き込まれることなく他のライブラリからレッスンを学ぶことができます。

一つのこと-サードパーティのライブラリを使用すると、車輪の再発明としてカウントすることができます。独自の古く、よく使用され、よくテストされたライブラリを既に持っている場合は、破棄する前に慎重に考えて、代わりにサードパーティのライブラリを使用してください。長期的には良いアイデアかもしれませんが、そこにたどり着く前に、膨大な作業と（ライブラリ間の微妙なセマンティックの違いから）厄介な驚きがたくさんある可能性があります。たとえば、自分のコンテナから標準ライブラリのコンテナに切り替えたときの影響を考えてみましょう。呼び出しコードの単純な翻訳では、標準ライブラリコンテナがイテレータを維持しないという事実は考慮されません。後で「ブックマーク」としてイテレータを保存する場合は、単純な翻訳を使用してもまったく実装できませんでした。

必要な機能を実行するコンポーネントがある場合、独自のバージョンの作成とデバッグに時間を費やすのはなぜですか？同様に、以前に同様の機能を実行するためのコードをすでに作成している場合、なぜそれを再作成しますか？

JoelはNot-invented-here に関する記事を書きました。この記事は、コードとソフトウェアを書き直すことが有用でない場合と有用でない場合について、多くを語っています。

ホイールの再発明は、何かがどのように機能するかを学ぶための素晴らしい方法です-そして、私はあなた自身の時間にその目的のために再発明することをお勧めします-しかし、アプリケーションを書くとき、すでに同じことを行う確立されたソリューションがある場合、なぜ再発明するのですか？

たとえば、JavaScriptコードをゼロから作成することは決してありません。代わりに、jQueryから始めて、そのフレームワークの上にアプリケーションを構築します。

私の個人的な経験則：

車輪を再発明することは、学習しているだけの場合に適しています。期限がある場合は、既存のホイールを使用することができます。

「悪い」または「悪」であることは、かなり強い言葉です。

いつものように、組み込みの実装よりも個人的な実装を選択する理由があります。昔は、Cプログラムはランタイムライブラリのバグに遭遇する可能性があったため、独自の実装を提供する必要がありました。

JVMは非常に厳密に定義されているため、これはJavaプログラムには当てはまりませんが、いくつかのアルゴリズムは依然として非常に適切なものです。たとえば、Joshua Blochは、Javaランタイムライブラリの非常に単純なバイナリ検索アルゴリズムにバグが含まれていることを説明しています。

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

将来のJavaディストリビューションで発見、修正、配布されました。

組み込みのバイナリ検索を使用する場合、Sunがこのバグ修正を見つけ、修正し、配布するためのハードワークを行うことにより、時間とお金を節約できます。「少なくともJava 6 update 10が必要」と言うだけで、彼らの仕事を活用できます。

このエラーが含まれる可能性が高い独自の実装を使用する場合、最初にバグを明示する必要があります。この特定のものは大規模なデータセットでのみ表示されるため、本番環境のどこかで発生するはずです。つまり、少なくとも1人の顧客が影響を受け、バグ修正の検索、修正、および配布中に実際のお金を失う可能性が高くなります。

したがって、独自の実装を優先することは完全に有効ですが、他の人の作業を活用するよりも高価になることが多いため、その理由は本当に良い方が良いです。

私は最近、このトピックに関する私の考えをブログに書きました。要約する：

1. それはですほとんど常にその機能は言語に組み込まれてthatsの場合は、ご自身を構築するために、特に真の悪。しかし、インターネット上で見つけた未熟な、疑わしく維持された、ひどく文書化されたフレームワークを、自分で書く可能性に対して評価しているなら、それは簡単なことかもしれません。

2. 車輪の再発明は、ソフトウェアのアンチパターンのひどい類推だと思います。これは、元のソリューションを改善できないことを意味します。それはナンセンスです。いわゆるホイールは一晩で陳腐化したり、所有者がメンテナンスを停止したりする可能性があります。ホイールは、使用されるシステムごとに異なる値を持ちます。そのため、より良いホイールを発明することは完全に可能です。

3. 独自のフレームワークを作成する主な利点の1つは、他の誰かのバグに対して責任を取る必要がないことです。（これがAmazonの哲学です。）このように考えてみてください。顧客に伝える方が良いのはどれですか？-

   「私たちのウェブサイトは壊れました。それは他の誰かのせいであり、作成者にバグを記録しました。待つこと以外にできることは何もありません。更新し続けます。」

   「当社のウェブサイトが壊れたため、すぐに修正できました。」

たぶん同じくらい効率的ですが、堅牢ですか？ライブラリを自分のロールオーバーで使用する最も説得力のある理由は、フレームワークが非常に多くの人々を使用しているため、バグをすばやく見つけて修正できるからだと思います。社内で開発されたライブラリは、同じくらい（またはそれ以上）の機能を提供しますが、ほとんどすべてのユースケースでテストを提供する数百万のユーザーを持つライブラリと競合することはできません。社内でそのようなテストに勝るものはありません。

ほとんどのフレームワークにはまだバグがあり、フレームワークはすぐに使えるソリューションを提供できないため、フレームワークと同じくらい効率的な彼自身の方法は非常にまれです。考えられないほとんどのプログラマーは、フレームワークレベルで何も書こうとしないでしょう。Googleで既製のソリューションを検索するだけです。賢明なプログラマーは、まず必要な機能を備えた無料のフレームワークがあるかどうかを確認し、ない場合は自分でソリューションを作成します。現在のプロジェクトの状況を説明するのが非常に困難な場合があり、開発者が最高の審査員です。

車輪の再発明は悪くありません。それは怠hardな人々が懸命に働くことを避けるために行った声明です。フレームワークの作成者でさえも再発明します。.NETフレームワーク全体が、COMが提供していたことを実行するために再発明されました。

一部の人にとっては不快かもしれませんが、この用語は、あらゆる形式のエンジニアが使用したり、物を作成または設計するトピックを参照したりする際に、常に不格好であることがわかりました。実際、今日のペースの速い世界で革新する圧力を考慮すると、それを不誠実と見なさざるを得ません。自分自身を繰り返す（または既存の適切なソリューションを無視する）ことは決して賢明ではありませんが、実際には、緑色の文字でいっぱいの黒い画面を見つめていない理由があります。

「壊れていない場合は修正しないでください」と理解していますが、そのようなフレーズは一部の人には無知に聞こえるかもしれません。しかし、宇宙旅行、レース、船積みなどのニーズに合わせて車輪を再発明しようとする現在の努力では、「車輪を再発明しない」も同様にかなり無知であり、見た目ほど賢くはありません。

私のバックグラウンドは多くのプロジェクトを主導することであり、多くのインターンやその他のグリーン開発者と協力しなければなりませんでした。タスクの範囲外の全体。しかし、私は決して革新や創造性を落胆させないだろうし、「車輪の再発明」から素晴らしいものが生まれるのを見てきました。

質問に対する私の実際の答え：車輪の再発明が悪いことである状況は2つだけです。

1. 本当に必要ない場合
2. あなたが持っている可能性があるときにそれをやっている他の男なら

編集：私はドライブバイダウン票で、私はいくつかの人を怒らせたに違いないことを見ることができます。私が付け加えたいことの一つは、このフレーズが常に私の大いなる欲求だったことです。私は私の2セントがかなりトロリーに聞こえるかもしれないことを理解していますが、私はトロールしたり、火災を引き起こしたり、怒らせるつもりはありません。

「車輪の再発明」についての議論は、ライブラリを使用することを選択するという間違った状況でよく使用されますが、ほとんど同じようなことではありません。

最近人気があり、フォームの処理に役立つライブラリ「forms-plus」を評価しているとしましょう。素敵なリンク先ページ、モダンでクールなグラフィック、そしてそれを取り巻くフォームを再びすばらしいものにすることを誓う-cult-（コミュニティを意味するおっと）があります。しかし、「フォームプラス」は「フォーム」の上に抽象化されています。「フォーム」は可能でしたが、扱いが面倒であったため、それを簡単にする抽象化が一般的になりつつあります。

常に新しい抽象化が行われています。それらを車輪と比較するのは難しいです。これは、実行する必要のある、すでに非常に複雑なデバイスに対する新しい制御デバイスと新しいマニュアルのようなものです。

この新しいデバイス「forms-plus」の評価は、個人的な経験によって異なります。以前にフォームを作成したことがない場合、「forms-plus」は非常に説得力があります。開始するのが簡単だからです。欠点は、「forms-plus」が漏れやすい抽象化であることが判明した場合でも、とにかく「forms」を学習する必要があることです。「forms-plus」なしでフォームを作成していた場合、新しいツールを習得する必要がある時間を考慮する必要があります。利点は、すでに「フォーム」を知っていることです。そのため、抽象化を恐れることはありません。新しいライブラリーが改善されなかった場合、おそらく新しいライブラリーはないので、新しいスターターの場合、短期的なメリットはしばしば大きくなります。長期的なメリットは、抽象化の質、採用率、

新しい抽象化 "forms-plus"を使用することと、ベアボーン "forms"を使用することの利点と欠点を慎重に評価した後、決定を下します。決定は私の個人的な経験に大きく基づいており、人によって異なる決定が行われます。必要最低限​​の「フォーム」を使用することを選択したかもしれません。たぶんやがてforms-plusはその背後にさらに動きを持ち、事実上の標準になりました。そして、多分私自身の実装がやっかいになり、forms-plusが現在行っていることをたくさんカバーし始めたかもしれません。この時点で来る人々は、私が車輪の再発明に熱心であり、代わりに既存のライブラリを使用すべきだったと批判するように引き付けられます。しかし、「forms-plus」について決定しなければならなかったときに、「forms-plus」に代わる複数の選択肢があった可能性もあります。

最終的に、適切なツールを選択することは、複雑な決定を下すことであり、「車輪の再発明」はあまり有用な観点ではありません。

私はこれについて少し記事を書きました-http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

私の経験では、再発明は実に素晴らしかった-非常に長くて退屈だ。使用するプログラミングモデルが正確にわからない場合は、自分で作成してください（時間とエネルギーがある場合）。これにより、これらのプログラミングモデルの正確な意味がわかり、最終的には優れたプログラマーになります。もちろん、クライアントのために働いていて、何かをすぐに立ち上げる必要がある場合は、おそらくいくつかの調査を行い、適切なソフトウェアを見つけたいだけでしょう。