全体的に私は約8年間プログラミングに携わっていますが、「仕事を成し遂げる」ために、オープンソースライブラリとスニペット(GitHubに気を付けて!)にますます依存しているように見えます。やがて私は独自の実装を書くことができることを知っていますが、全体的な設計に集中するのが好きです。
これは正常ですか(非企業環境)?私の「プログラミング」が異なるライブラリを一緒に接着することにほかならない場合、何が問題になるのでしょうか?
「ホイールを再発明しない」については知っていますが、1つのホイールを発明しなくなった場合はどうなりますか?
ホイールを再発明する代わりにライブラリを使用する:すばらしい!それは誰もがそれをすべき方法です。あなたはすでに行われていることをするために報酬を得ていません。
スニペットの使用:コピーアンドペーストの内容を理解している限り、すべての一貫性を保つために時間を費やしている限り(異なるスタイルやアプローチのパッチワークではなく)、何も問題はありません。
優れたプログラマーは優れたコードを記述します。優れたプログラマーは優れたコードを盗みます。
コーディングは実際には最低レベルのプログラミングです。あなたが得ることができる抽象化のレベルが高いほど、あなたはより優れたプログラマーです。正しいライブラリ(必ずしもオープンソースのライブラリではない)を選択する適切にそれらを接続して構成を維持することは、すべてを自分で書くよりもはるかに困難ですが、より効率的で時間とコストを節約できます。
私は自分のライブラリを書くのが大好きです。また、プロジェクトを予定どおりに完了することも大好きです。時間の経過とともに、most優れたプログラマーは便利で再利用可能なビットのコレクションを構築すると思います。あなたのことはわかりませんが、5年前に書いたライブラリを使うたびに気持ちがいいです。
時間の経過とともにテストされ、愛されてきたライブラリコードの使用には絶対に何もない誤りがあります。あなたはそれがどのように機能するかを知っており、その複雑さを当てにすることができ、素早く実装することができます。
そうは言っても、あなたはライブラリのコードを理解していると思います。十分な時間が与えられれば、同様の品質のものを実装できると思います。
私はcouldが標準Cライブラリを実装する本当に優れたCプログラマーを何人か知っています。趣味の時間の中で最も楽しかったことの1つは、HelenOSのCライブラリでの作業でした。
したがって、好奇心を持ち、学び続ける限り、ライブラリコードの使用に問題はありません。言うまでもなく、理解できないコードはnotを使用してください。
この質問では、他の人よりも1つ上手くいきます。ライブラリの「クライアント」開発者がそのライブラリのコードを「理解」する必要があるとは思いません。
私は(一部に比べて)比較的新しいiPhone開発者です。私が毎日自分で生成することは決してできなかった多くのライブラリーがあり、そのコードは頭を悩ませています。 PROVIDEDで少しでも問題ありません。
1)これらのライブラリへのインターフェースを完全に理解しています(私はASIHTTPRequest忍者です!)
2)私は一般的に広く使用されているライブラリを選択しているので、問題が十分に調査され、調査されていることを確認できます(例:ASIHTTP、Stig BrautasetのJSONライブラリ、Facebookのobj-cライブラリなど)
3)失敗#2、それは私がcouldそれを通して自分の道を選び、発見/修正/カスタマイズが必要なものを見つけ/修正/カスタマイズするのに十分簡単です。
その#2はこれの論争の一部になるだろう、私は賭けます。実際、私はオープンソースコミュニティに依存しています。これは、私よりも確かに経験が豊富で、おそらくより賢い開発者のコミュニティです。しかし、それがオープンソースの要点です。だから、あなたは行きます。
コードの再利用は非常に良い考えです。冗長性が減少し、保守性が向上します。
タイトルは、コードをライブラリとして使用していることを示していますが、質問のテキストは、ソースコードを新しいプロジェクトにコピーしている可能性があることを示しています。できるだけ他の開発者のコードをライブラリとして使用することにします。
コードが不良であるか、何らかの理由で壊れているか、アプリケーションに適合しないモデルに基づいている場合は、問題があります。その場合、理解しようとするよりもmightコードの一部またはすべてをスクラップしてゼロから始める方が簡単ですwhyコードは所定の方法で記述されています。ただし、参照用に他のコードを保管してください。解決方法がわからない問題に遭遇する場合があります。他の開発者がおそらく同じ問題に遭遇した可能性があります。彼らがそれをどのように解決したかを確認することは価値があります。
通常、大量のソースコードをコピーすることはお勧めできません。コードが会社の別のアプリケーション用に開発された場合、両方のアプリケーションで使用するにはコードをライブラリに抽出して再利用するにする必要があります。 コードをコピーしないでください。コードをコピーすると、1つの共通コピーではなく2つのコピーを維持する必要があります。
ライブラリを使用する際に警告を出したいのですが。 Perl and R(およびJavaの一部)で科学ライブラリを頻繁に使用する私は、ひどいオーバーヘッドコストを回避するためにライブラリにハッキングする必要がしばしばありました。ライブラリの使用は素晴らしいですが、ますます多くのライブラリ自体が他のライブラリに依存しており、標準ライブラリを使用して比較的一般的なタスクを実行する3番目のライブラリを呼び出します。そして、プロセスの各ステップでは、入力と出力のいくつかのチェックが必要です。これらのチェックの多くは完全に冗長ですが、それでもアプリケーションに重きを置いています。ループで使用すると、かなりの重さになる可能性があります。
次に、ライブラリが常に下位互換性を維持していること、またはバグが含まれていないことを確認できません。実際、すべてのライブラリにはいくつかのバグが含まれていますが、それがコードの性質です。したがって、ライブラリへの依存度が高いほど、コードに入力する潜在的なバグが多くなります。そして、ライブラリに再度ハッキングすることなく簡単に解決できないバグ。
ライブラリの使用は非常に賢明な決定ですが、if if only only ifは、ライブラリとその動作をかなりよく理解しています。
私は知っています、痛いと思い、コンピュータは安いですが、それでもまだです。考えないことはもっと傷つけることができます。
それは一般的には良い考えであり、法的な問題が存在しない限りです。
ただし、ライブラリが何をどのように実行するかを理解するために時間をかけてください。 「マジック」ライブラリーを使用して、理解できないことを処理することは、誤って使用したためにライブラリーの一部を吹き飛ばす良い方法であり、それを修正する方法がわかりません。
コードを合法的に再利用することには、マイナス面がほとんどなく、2つの大きなプラス面があります。
ライブラリとコードスニペットの使用量が多いと、プログラマーは下手になりますか?
ライブラリとコードスニペットを適切な場所で使用している場合、'No'であっても、それが悪いプログラマであるという意味ではありません。それはあなたが適切な場所で他の人の知恵を適用できる賢いプログラマーであることを意味します。
ただし...
ライブラリとコードスニペットをfindするのに時間がかかるため、自分でコードを記述できず、ライブラリを見つけたり、ささいなタスクを実装するためのコードスニペット、次に'Yes'、あなたは悪いプログラマです。
補完の目的で、カウンター引数を許可します: http://web.archive.org/web/20150326134617/https://michaelochurch.wordpress.com/2015/03/25/never-invent-here-the -even-worse-sibling-of-not-invented-here /
私が「ここでは決して発明しない」(NeIH)と呼ぶ考え方。その考え方により、外部資産は過大評価され、しばしば暗黙的に信頼され、エンジニアは既製の資産の癖に適応するのにより多くの時間を費やすことができ、独自の資産を構築する時間を短縮できます。
常にバランスがあります。
いいえ。プログラマは、すでに存在するライブラリを使用する必要があります。ホイールを再発明する必要はありません。より良い方法があればそれを試すことができますが、それ以外の場合は、同じコードを書くことで実際に何をするのでしょうか。唯一のことは、コードが何であるかを知る必要があるということです(それが重要な場合のみ)。
他の回答の理由に加えて、コードを使用しないこと(問題に適している限り)は非倫理的であると考えることができます。理由は次のとおりです。
どちらも事前に判断するのは難しいことに注意してください。
また、一般にanit-patternと呼ばれる Not Invented Here も参照してください。