「車輪を再発明しないでください」は人間の記憶の限界を無視しますか？
HaskellとF＃で働いていることの1つは、私よりも賢い大学の誰かがおそらく私がやっていることの抽象化をすでに見つけているということです。同様に、C＃やオブジェクト指向プログラミングでは、私が何をしていても、おそらく「それ」のためのライブラリがあります。
プログラミングで抽象化を再利用することに重点が置かれているため、1）短くて汚いものを自分でコーディングするか、2）同じ時間をかけて他の人のより堅牢なライブラリ/ソリューションを見つけてそれを使用するかというジレンマを感じることがよくあります。
最近のように、ここのコーダーの1人がCSVファイルの（デ）シリアライザーを作成しました。NET標準がまだ付属していない場合は、そのようなものをオンラインで見つけるのはおそらく非常に簡単だと思わずにはいられませんでした。 API。
私は彼を責めませんが、.NETで何度か作業して、私が知っていることに基づいてソリューションにパッチを適用しましたが、メソッド呼び出しやオブジェクトなどがあったことに気づきました多くの場合、同じライブラリにあります、それは私が望んでいたことをしました、そして私はそれについて知りませんでした。
これは単なる経験不足の兆候ですか、それとも、新しいものを書くことと古いものを再利用することの間には常にトレードオフの要素がありますか？私が最も嫌うのは、私がすでに知っていて忘れていた解決策に出くわしたときです。最近のほとんどの言語にあらかじめパッケージ化されている膨大な量のコードを、1人の人間が消化できないように感じます。
最初に、ライブラリまたはサードパーティのソリューションがすでに存在する可能性が高いほど一般的/再利用可能な「コンポーネント」を特定する方法を学ぶ必要があります。これを実行したら、優れた開発者であっても、同じ問題に数え切れないほどの時間を費やしている無数の開発者の集合的な経験が、あなたがこれまでにできるよりも優れたソリューションを生み出している可能性が高いことを認識してください。 never "車輪を再発明する"必要があるという意味ではありませんが、そうすることを選択した場合は、DAMNが正当な理由を持っていることになります。
プログラミングで抽象化を再利用することに重点が置かれているため、1）短くて汚いものを自分でコーディングするか、2）同じ時間をかけて他の人のより堅牢なライブラリ/ソリューションを見つけてそれを使用するかというジレンマを感じることがよくあります。
ifでも、既存のライブラリ/ソリューションを見つけるのに、自分で書くのと同じ時間がかかります。自分で行うことは、維持する必要があることも覚えておいてください。 永遠に。ホイールを再発明するだけでなく、ピットクルー全体がホイールを動かし続けることができます。もちろん、一部のライブラリにはバグがあるか、メンテナンスが不十分ですが、サードパーティのソリューションを選択する際にこれらのことを覚えておく必要があります。
特定の言語であろうとプログラミング一般であろうと、これは経験不足の兆候である場合があります。ただし、適合が明らかでない場合は、正確に必要なものおよびそれ以上を実行する独自のコードをロールする方がよい場合があります。ジェネリックライブラリは便利な場合が多いですが、単に必要のない要件に合わせて構築できます。場合によっては、このレベルのジェネリック性により、必要以上に問題が発生する可能性があります。
例：私の小さな一人のプロジェクトでは、「実際の」ロギングライブラリを使用することはありません。 printステートメントと少しアドホックな構成を使用します。 printステートメントが私の目的のためにうまく機能するとき、私がこれまでに使用するよりもはるかに多くの機能を備えたロギングライブラリをセットアップして構成することに煩わされたくありません。また、使用したいコンパイラ/インタプリタのバージョンと互換性がない可能性がある、配布する必要がある、などの別の依存関係も必要ありません。
プログラミングの世界へようこそ。この問題は、あなたとあなたの将来の同僚の間で多くの意見の相違の対象となるでしょう。 2つのオプションがあります。
- 自分で転がして。
- 他の誰かのソリューションの上に何かを構築します。
両方のソリューションが適切な場合があると思います。たとえば、ORMの独自のCSVパーサーをロールバックしないようにしたいのですが、ほとんどの場合、面倒な作業なので回避できます。一方、図書館はしばしば制限されています。私が取り組んできたすべてのプロジェクトで、問題を完全に解決するライブラリに遭遇したと思いますそうでない場合この1つの欠点について。あるいは、ライブラリは、最初に何かを始めたときに必要なものである場合もありますが、変更を加える必要があると、ヘルプよりも害が大きくなります。
ただし、一般的には、「正しい」答えは存在しないため、見つけようとしないことをお勧めします。疑わしいときは、腸を使ってください。私はかつて、経験はあなたが犯した愚かな間違いの数によって定義されると誰かが言うのを聞いたことがあります。したがって、通常、あなたは何かを学ぶか、うまくいく何かを作るでしょう。いずれにせよ、それはすべて悪いわけではありません。
これ（または同様のこと）は、フレームワークが深刻な内部プラットフォーム効果の影響を受けていた以前の仕事でよく起こりました。
基本的に、彼らのコードベースは初期のWindows C/C++から進化し、MFCでコンパイルされ始めた-それで、メンテナーはMFCと古い社内データ構造とウィンドウコンポーネントの混合を始めました。内部プラットフォームは十分に文書化されていませんでしたが、いくつかの内部機能により、そのプラットフォームで何かを行うには「方法」だったと思われます。会社の内部フレームワークを使用して作成するよりも、（MFCの基礎から）自分のものを最初から作成する方が簡単で迅速であることがよくあります。
（さて、これはあなたの最初のポイントとはほぼ逆のようです-しかし、原則は同じです、へへ！ええ、時々、既存の再利用可能なものを見つけるために時間と労力を費やすよりも、あなた自身のことをする方が本当に速いです解決。）