ライブラリとコードスニペットを多用しない具体的な理由はありますか？[閉まっている]

全体的に私は約8年間プログラミングに携わっており、「仕事をやり遂げる」ためにオープンソースライブラリとスニペット（GitHubを気にせず）にますます依存しているように思えます。やがて自分の実装を書くことができることは知っていますが、全体的な設計に集中したいです。

これは正常ですか（非企業環境）？私の「プログラミング」が異なるライブラリーを一緒に接着すること以外の何物でもない場合、何がうまくいかないのでしょうか？

「車輪を再発明しない」ことは知っていますが、もう1つの車輪を発明しないとどうなりますか？

車輪を再発明する代わりにライブラリを使用する：すばらしい！それが誰もがすべきことです。すでに行われたことを行うために報酬を得ることはありません。

スニペットの使用：コピーアンドペーストの内容を理解し、（異なるスタイルやアプローチのパッチワークではなく）一貫性を保つために時間をかける限り、問題はありません。

優れたプログラマーは優れたコードを書きます。優れたプログラマーは優れたコードを盗みます。

コーディングは、実際にはプログラミングの最低レベルです。抽象化のレベルが高いほど、プログラマの質が向上します。適切なライブラリ（必ずしもオープンソースのライブラリである必要はありません）を選択し、それらを適切に接続し、構成を維持することは、すべてを自分で書くよりもはるかに難しく、より効率的で時間とコストを節約します。

私は自分のライブラリを書くのが大好きです。また、プロジェクトを時間通りに完了させることも大好きです。私は、時間の経過とともに、ほとんどの優秀なプログラマーが有用で再利用可能なビットのコレクションを構築すると考えています。私はあなたのことは知りませんが、5年前に書いたライブラリを使うたびにいい気分になります。

テストされ、長い間愛されてきたライブラリコードを使用しても、まったく問題はありません。あなたはそれがどのように機能するかを知っており、その複雑さを頼りにでき、あなたはそれを素早く実装することができます。

そうは言っても、ライブラリのコードを理解していることを前提としています。十分な時間を与えられれば、同様の品質の何かを実装できると思います。

標準のCライブラリを実装できる本当に優秀なCプログラマーを知っています。そのうちの数人は、単に学習/研ぎの練習として使用しています。趣味で過ごした中で一番楽しかったのは、HelenOSのCライブラリで作業したことです。

したがって、好奇心を持ち続けて学習し続ける限り、ライブラリコードを使用しても問題はありません。それはあなたがすべきことは言うまでもないない、それの使用は、それがどのように機能するかを理解するための努力でない限り、あなたは理解していないというコードを使用します。

私はこの質問で他の人よりもうまくいきます。ライブラリの「クライアント」開発者がそのライブラリのコードを「理解」する必要はないと思います。

私は（一部と比較して）比較的新しいiPhone開発者です。私が毎日自分で生成することはできなかったライブラリをたくさん使用しており、そのコードは頭上にあります。ほんの少しの提供では関係ありません：

1）それらのライブラリへのインターフェースを完全に理解しています（私はASIHTTPRequest忍者です！）
2）一般的に広く使用されているライブラリを選択しているので、それらがうまく行き過ぎて問題を調査したことを確信できます（例：ASIHTTP、Stig BrautasetのJSONライブラリ、Facebookのobj-cライブラリなど）
3）＃2に失敗すると、それを介して自分の道を選び、検索/修正/カスタマイズが必要なものを見つけ/修正/カスタマイズできるほど簡単です。

その＃2はこれの論争の的となる部分になるだろう、と私は賭けている。実際、私はオープンソースコミュニティに依存しています。オープンソースコミュニティは、私よりも確かに経験が豊富で、かなり賢い開発者のコ​​ミュニティです。しかし、それがオープンソースの重要なポイントです。それで、そこに行きます。

ライブラリを使用する際に警告を出したいです。PerlおよびR（およびJavaの一部）の科学ライブラリの頻繁なユーザーとして、ひどいオーバーヘッドコストを回避するために、ライブラリにハッキングする必要がしばしばありました。ライブラリの使用は素晴らしいことですが、ますます多くのライブラリ自体が他のライブラリに依存しており、標準ライブラリを使用する3番目のライブラリを呼び出して、かなり一般的なタスクを実行しています。また、プロセスの各ステップでは、入力と出力のチェックが必要です。これらのチェックの多くは完全に冗長ですが、それでもアプリケーションに負荷がかかります。そして、ループで使用すると、かなり重くなり始めます。

それに加えて、ライブラリが常に後方互換性を維持しているか、バグが含まれていないかを確認することはできません。実際、すべてのライブラリにはいくつかのバグが含まれており、それがコードの性質です。したがって、ライブラリに依存しているほど、コードに入力される潜在的なバグが増えます。そして、これらのバグは、ライブラリに再度ハッキングすることなく簡単に自分で解決することはできません。

ライブラリの使用は非常に賢明な決定ですが、ライブラリとその動作をよく知っている場合に限ります。

痛いことやコンピューターを考えることは安いのですが、それでもです。考えないと、もっと痛くなることがあります。

通常、大量のソースコードをコピーすることは適切ではありません。会社の別のアプリケーション用にコードが開発された場合、両方のアプリケーションで使用されるライブラリにコードを抽出して再利用する必要があります。 コードをコピーしないでください。 コードをコピーすると、1つの共通コピーではなく2つのコピーを維持するように強制されます。

コードの再利用は非常に良い考えです。冗長性を減らし、保守性を促進します。

タイトルは、コードをライブラリとして使用していることを示していますが、質問のテキストは、ソースコードを新しいプロジェクトにコピーしている可能性があることを示しています。他の開発者のコ​​ードを可能な限りライブラリとして使用することに固執します。

コードが悪いか、何らかの形で壊れているか、アプリケーションにあまり適合しないモデルに基づいている場合は問題があります。その場合、特定の方法で記述された理由を理解しようとするよりも、コードの一部または全部を破棄してゼロから始める方が簡単かもしれません。ただし、参照用に他のコードを保持してください。解決方法がわからないという問題に遭遇する可能性があります。他の開発者がおそらく同じ問題に遭遇した可能性があり、どのように解決したかを見る価値があります。

それは一般的に良い考えです、長い間法的問題は存在しません。

ただし、ライブラリが何をし、どのようにそれを行うかを理解するために時間をかけるようにしてください。「マジック」ライブラリを使用して理解できないことを処理することは、間違った使い方をしたためにその一部を爆発させる良い方法であり、それを修正する方法がわかりません。

法的にコードを再利用することには、マイナス面はほとんどなく、2つの大きな利点があります。

1. それは仕事を終わらせます。これは、専門能力開発にとってより重要なものです。最終的には、プログラマ以外のほとんどの人を困らせるような事態を起こす方法を知っているので、給与の高い仕事ができます。再利用することで、その目標をより早く達成できるので、仕事の中でより貴重になります。
2. ものを学びます。これが自己改善のより重要な理由です。他の人が書いた良いコードを読むことよりも、コーディングを改善する良い方法はありません。他の人が書いた悪いコードでさえ、通常は何かを教えてくれます！また、ライブラリ、API、言語、またはドメインがどのように機能するかを理解するのに、他の人が既に作成したソリューションを読んで改善することほど良い方法はありません。既存のソリューションでは必要なことをまったく実行できないため、既存のコードを再利用すると、通常、両方のことが起こります。ソースの修正は知識の向上の源です。

ライブラリとコードスニペットの使用量が多いと、あなたはプログラマーになりませんか？

適切な場所でライブラリとコードスニペットを使用している場合、「いいえ」は、あなたが悪いプログラマーであることを意味しません。それは、あなたが他の人の知恵を適切な場所に適用できる賢いプログラマーであることを意味します。

しかしながら...

ライブラリとコードスニペットを見つけるには時間がかかるため、自分でコードを書くことができず、些細なタスクを実装するためにライブラリとコードスニペットを見つけるのに何時間も費やす必要がある場合、「はい」、あなたは悪いプログラマーです。

いいえ。プログラマは、すでに存在するライブラリを使用する必要があります。車輪を再発明する必要はありません。より良い方法があれば、それを選ぶことができます。そうでなければ、同じコードを書く際に実際に何をするのでしょうか。唯一のことは、コードが何であるかを知る必要があるということです（それが重要な場合のみ）。

他の回答の理由に加えて、コードを使用しない（問題に適している限り）ことは非倫理的であると見なすことができます。

1. 意図的に雇用主の時間を無駄にしている可能性がありますOR
2. 意図的に少ない製品を提供している可能性があります

これらの両方を事前に決定することは困難です。

また、一般にanit-patternと呼ばれるNot Invented Hereを見てください。

完了のために、次のカウンター引数を許可します：http : //web.archive.org/web/20150326134617/https : //michaelochurch.wordpress.com/2015/03/25/never-invent-here-the-even-worse -ここで発明されていない兄弟/

私が「Never Invent Here」（NeIH）と呼ぶメンタリティ。その考え方により、外部資産は過大評価され、暗黙的に信頼されていることが多く、エンジニアは既成資産の癖に適応する時間を多く費やし、独自の資産を構築する時間を短縮できます。

常にバランスがあります。

どうしても必要な場合を除き、ライブラリを使用しないためです。依存関係により、移植性と寿命が制限されます。私はソフトウェア開発に34年間携わっており、侵食（変更）によって破壊されることなく、少なくとも1つのプログラムを3年以上継続したいと考えています。

17年前の答えであるCOM（コンポーネントオブジェクトモデル）は、理論上は素晴らしいですが、実際には疑わしく、再利用可能なコンポーネントではありません。必要な場合にのみ、非常に基本的なコンポーネントのみを使用します。

APIとSDKはあまり使用しません。ライブラリから実際に使用するコードの行数を分解すると、それらを動作させるために費やす時間とそれらを書くために費やす時間は、洗い流しだと思います。SDKの使用を完全にやめましたが、オーバーヘッドは極端です。

フレームワーク：Zend、Silverlight、WCF、.NET、階層化されたシステム、はい、それらは初期開発をスピードアップできますが、限界に達したとき、クラックの修正に費やす時間は努力するだけの価値はありません。彼らは何歳で、侵食に対して不浸透性ですか？

私は自分のライブラリだけでJavaScriptとHTMLに行きました。最も一般的なステートメントタイプのみを使用してJavaScriptを削除しました。私は10年後には続く何かを書くことができると思います。

それはすべて依存しています。ゲームをコーディングしている場合、ライブラリ（例：Allegro）を使用するようになりますが、他の人のコードをコピー/盗み/借用している場合、プログラマとは見なされません。私は、車輪を再発明するのではなく、合理的なポイントまで言うのです。他の人が書いたスニペットのプログラム全体を作成しないでください。あなたのコンピュータに座って、自分でそれをしてください...コードを盗むのを止めてください。最近、人々はあまりにも怠け者になり、ただコピーして貼り付けています。