「車輪を再発明しないでください」は人間の記憶の限界を無視しますか？

HaskellとF＃で働いていることの1つは、私よりも賢い大学の誰かが、おそらく私がやっていることの抽象化をすでに見つけているということです。同様に、C＃とオブジェクト指向プログラミングでは、私がやろうとしていることには関係なく、おそらく「it」用のライブラリがあります。

プログラミングの抽象化を再利用することに重点が置かれているため、1）短くて汚いものをコーディングするか、2）他の誰かのより堅牢なライブラリ/ソリューションを見つけるために同じ時間を費やし、それを使用することの間でジレンマを感じることがよくあります。

最近のように、ここのコーダーの1人がCSVファイル用の（デ）シリアライザを作成しましたが、.NET標準がまだ付属していない場合、そのようなものはおそらくオンラインで見つけるのが非常に簡単だと思わずにはいられませんでしたAPI。

私は、.NET Iで働いて数回のみ、いくつかのメソッド呼び出しまたはオブジェクトか何かがあったことを実現するために、一緒に私が知っている内容に基づいてソリューションをパッチしてきた、けれども彼を責めないで 、多くの場合、同じライブラリに、何をやっています欲しかったのですが、それについて知りませんでした。

これは単に経験不足の兆候ですか、それとも新しいものを書くことと古いものを再利用することの間には常にトレードオフの要素がありますか？私が最も嫌いなのは、すでに知っていて忘れていたソリューションに出くわしたときです。最近、ほとんどの言語にプリパッケージされている大量のコードを消化できない人がいるように感じます。

最初に、ライブラリまたはサードパーティのソリューションが既に存在する可能性が高いほど十分に汎用的/再利用可能な「コンポーネント」を識別することを学ぶ必要があります。それができたら、たとえあなたが優秀な開発者であっても、同じ問題に数え切れないほどの時間を費やしている無数の開発者の集合的な経験が、これまでにないほど良いソリューションを生み出している可能性があることを理解してください。それは決して「車輪を再発明する」べきではないという意味ではありませんが、そうすることを選択した場合、そうするためのDAMNの正当な正当性があります。

プログラミングの抽象化を再利用することに重点が置かれているため、1）短くて汚いものをコーディングするか、2）他の誰かのより堅牢なライブラリ/ソリューションを見つけるために同じ時間を費やし、それを使用することの間でジレンマを感じることがよくあります。

それの価値は、それさえも言及する場合、それはそれを自分でやってすることも、あなたがそれを維持する必要がありますを意味していることを覚えて、それを自分で書くことがないよう、それは既存のライブラリ/解決策を見つけるためにあなたの時間の同じ量を取る永遠に。車輪を再発明するだけでなく、ピットクルー全体を動かして車輪を動かし続けます。もちろん、いくつかのライブラリはバグがあるか、メンテナンスが不十分です。しかし、これらはサードパーティのソリューションを選択する際に留意すべきことです。

これは、特定の言語であれ、一般的なプログラミングであれ、経験不足の兆候である場合があります。ただし、フィットが明らかでない場合は、自分が望むものを正確に実行し、それ以上何もしない独自のコードをロールする方が良い場合があります。汎用ライブラリは、多くの場合便利ですが、単に持っていない要件のために構築することができます。場合によっては、このレベルの汎用性により、必要以上にトラブルが発生する可能性があります。

例：小さな個人プロジェクトでは、「実際の」ロギングライブラリを使用しません。私が使用してprintステートメントプラス少しアドホック設定を。printステートメントが目的に合っている場合、これまで使用した機能よりもはるかに多くの機能を備えたロギングライブラリのセットアップと構成に煩わされたくありません。また、使用したいコンパイラー/インタープリターのバージョンと互換性がなく、配布する必要があるなど、別の依存関係も必要ありません。

プログラミングの世界へようこそ。この問題は、あなたとあなたの将来の同僚との間の多くの不一致の主題になります。次の2つのオプションがあります。

1. 独自のロール。
2. 他の人のソリューションの上に何かを構築します。

両方のソリューションが適切な場合があると思います。たとえば、かなり退屈な作業であるため、ORMのCSVパーサーをロールバックすることを避けることができます。一方、ライブラリはしばしば制限されています。私が取り組んだすべてのプロジェクトで、この欠点がなければ、問題を完全に解決するライブラリに出会ったと思います。または、ライブラリは、最初に何かを始めたときに必要なものである場合がありますが、変更を加える必要がある場合に役立つよりも害が大きい場合があります。

ただし、一般的には、「正しい」答えが存在しないため、見つけようとすることはお勧めしません。疑わしいときは、あなたの内臓を使ってください。経験は、あなたが犯す愚かな間違いの数によって定義されると誰かが言うのを聞いたことがあります。そのため、通常は何かを学ぶか、機能する何かを作成します。いずれにせよ、それはすべて悪いわけではありません。

これ（または同様のこと）は、フレームワークが深刻な内部プラットフォーム効果に苦しんでいた以前の仕事でよく起こりました。

基本的に、コードベースは初期のWindows C / C ++から進化し、MFCでコンパイルされるようになりました。したがって、メンテナーはMFCと古い社内データ構造およびウィンドウコンポーネントを混合し始めました。内側のプラットフォームは十分に文書化されていませんでしたが、提供された内部機能のために、その製品で物事を行うための「方法」と思われました。会社の内部フレームワークでそれを行う方法を考え出すよりも、（MFCの基礎から）ゼロから自分のものを書く方が簡単かつ迅速であることがよくわかりました。

（わかりましたので、これはあなたの最初のポイントとほぼ反対のようです-しかし、原理は同じです、へー！時々、既存の再利用可能なものを見つけるために時間と労力を費やすよりも実際に自分のことをする方が本当に速いです解決。）