作成したプログラムがどのように機能するかを知らずに生きても大丈夫ですか？

つまり、立ち往生しているときに問題を解決できる便利なライブラリがあり、これを解決する方法がわからない、または使用しているプログラミング言語の知識があれば...たとえば、C ++のBoostまたはJavaScriptのJQueryまたはSpring Java ...彼らは数秒で問題を解決し、あなたは彼らがどのようにそれをやったのか気にしません（彼らはあなたがプログラミングしているのと同じ言語で書かれているにもかかわらず）...だから私は一人ではなく問題の解決策を一から作成できるか、それとも標準的な方法ですか？

自分で問題を解決する方法を理解せずに、代わりにライブラリを使用しても大丈夫ですか？

一般的にいや、そうではありません。

ライブラリを使用すると、問題を解決する方法を考え出し、ソリューションをデバッグしてから保守するという（難しい！）作業を省くことができます。ただし、使用する場合は、その仕組み、つまりソリューションが実際に問題を解決する理由を理解しておくことをお勧めします。メカニックとして働いている場合、車、エンジン、および車のエンジンを構築するロボットを発明する方法を知る必要はありません-しかし、部品の仕組み、それらがすべて何をするのか、そしてそれらがどのように一緒にフィット！

これが、多くの人々が非常に専門的になるのを目にする理由です-多くの場合、単一の言語、単一のプラットフォーム、単一のフレームワーク、およびライブラリーのセットで作業する方法を学ぶだけです。

そうは言っても、学ぶ時間はあまりありません。場合によっては、ショートカットを使用する必要があります-それらを使用しますが、ショートカットであることを知っています。たぶん、時間があるなら、あなたはそれについて理解することができることを知るためにライブラリについて十分に読んだだけかもしれません。または、実際に呼び出す必要のある2つの関数だけを把握し、正しく呼び出すのに十分なだけにすることもできます。これは近道であり、価格がかかります。通常、誰かがコードを修正しなければならない場合（おそらく、より古く、経験豊富な方）になります。

いったんcomputerworld.com.auが尋ねビャーネ・ストロヴストルップを「あなたは新進気鋭のプログラマのための何かアドバイスはありますか？」
そして彼は答えた「コンピュータサイエンスの基礎を知ってください：アルゴリズム、マシンアーキテクチャ、データ構造など。アプリケーションからアプリケーションへと盲目的にコピーするだけではありません。あなたがしていること、それが機能していること、そしてなぜ機能しているのかを知ってください。 5年後に業界がどうなるのか、それから何をするのかを知っているので、一般的で有用なスキルのポートフォリオを収集し、より良い、より原則的なコードを書くようにしてください。低レベルの「ハッキング」アクティビティが少なくなります（プログラミングも工芸品ですが、単なる工芸品ではありません）。分野の古典やより高度な教科書から学びます。簡単に消化できる「方法」に満足しないでください。ガイドとオンラインドキュメント-浅いです。」
それが何のために必要であるかについてあなたの疑念を明確にすることを願っています真のプログラマーであり、誰でも1人になるために必要なもの。

はい-そして私達は皆それをします！

たとえば、Mac関連のグラフィックコードで修正していた非常に単純なバグを考えてみましょう。バグを取り巻くコードにはいくつかのステップが含まれていました。

1. まず、Objective Cメソッドはmalloc（）を使用してピクセルバッファーを割り当て、それをObjective Cオブジェクトにアタッチします。
2. その後、何かが起こり、CルーチンがObjective Cオブジェクトにメッセージを送信し、ピクセルバッファーを取得します。
3. Cルーチンは、jpeglibを使用してピクセルバッファーの内容を圧縮し、TCP / IP接続を介して送信します。

そこには非常に多くのことが起こっています！以下にいくつかを示します。

• メモリが物理的に連続しており、線形にアドレス可能であると想定するmalloc（）を実装する動的メモリアロケータ。
• 断片化された物理RAMとディスク領域（RAMとは異なる物理デバイス）の両方を、物理的に連続した線形にアドレス可能なRAMのような動的メモリアロケーターに見えるものにマッピングする、基盤となるDarwinカーネル仮想メモリシステム。
• Objective Cのオブジェクトシステム
• Mac OSランタイムメッセージングシステムと、Objective Cオブジェクトと対話する方法
• 離散コサイン変換アルゴリズムを使用するJPEG非可逆ラスターイメージ圧縮標準のjpeglibライブラリの実装
• データを送信するためのユーザースペースネットワーキングルーチン。さまざまなTCPおよびIPプロトコル実装を介して呼び出し、OSカーネルを呼び出します。次に、ネットワークで有効にしたものに応じて、イーサネットポートのドライバー、wi-fiチップ、または通常はUSBまたはFirewireドライバーを呼び出します。

これらすべてが実際にどのように実装されているかの詳細をすべて理解していますか？絶対にしないでください！地球上には非常に多くの人々がいることを疑います。だから私はそれについて心配しないでください。

しかし、好奇心をそそり、使用するライブラリとツールについて少なくとも少し学ぶことは良いことです。最初にプログラミングを始めたとき、コンパイラとオペレーティングシステムは魔法ではないことを知っていましたが、確かにそのように思えました。これらのことについての好奇心にふけることにより、私は非常に多くのことを学び、これまで素晴らしいキャリアを積みました。

私たちがライブラリを使用する主な理由は、常に「車輪を再発明」せず、解決しようとする問題を抽象化することだと思います。自分で問題を解決しようとすることもできますが、それには時間がかかります。

ただし、ライブラリによって問題がどのように解決されるかを知っているか推測する必要もあると感じています。これは通常、ライブラリのユーザーマニュアルに記載されており、オープンソースソフトウェアを使用すると、いつでも自分でコードを見ることができます。

また、とにかく難しい部分を抽象化することで問題を解決しますが、なぜそれがうまくいかないのでしょうか？

ライブラリは、一般的な問題の解決策を提供するためにあります。解決しようとしている特定の問題を解決できるかどうかを決める必要があります。彼らは問題を解決する方法を知らないことに代わるものではありません。たとえば、アプリケーションにハッシュテーブルが必要な場合、ハッシュテーブルが解決する問題を理解するのに十分な知識が必要です。使用しているライブラリのパフォーマンスを評価して、アプリケーションで機能するかどうかを判断できる必要があります。ライブラリを使用して不十分な技術知識をカバーすることは正しいユースケースではないと考えています。ライブラリを使用するかどうかの決定は、ライブラリを使用することで開発をスピードアップし、テスト済みの信頼できるソリューションを提供するかどうかを中心に行う必要があります。ライブラリを使用するという決定は、特定の問題を解決できないプログラマーを中心にすべきではありません。

本当にあなた次第です。

使用しているツールを理解すればするほど、それらを活用できるようになります。

たとえば、jQueryを使用することはめったにありませんが、どうすればjQueryを利用すべきか、Mootoolsなどの他のフレームワークと共存させる方法を知る必要があります。

また、すぐにUDKでgamedevに冒険します。それについて理解すればするほど、それを邪悪な意志に曲げることができると確信していますが、簡単なチュートリアルに従うこともできます。私は最初の、ほんの少し余分な時間と頭脳周期を選択し、より良くて簡単な結果を得るでしょう。

領域とプロセスの一部を知ることが重要です。

たとえば、画像処理ライブラリを使用しているとします。ガウスぼかし、変換、色空間についてすべてを本当に知る必要がありますか？いいえ。しかし、その理由を知る必要があります、そもそもライブラリを使用ます。または、フレームワークのソート機能。使用されている実際のソートアルゴリズムを知る必要がありますか？ほとんどの場合、いいえ。しかし、なぜデータをソートする必要があるのか​​を知る必要があります。

一方、コンパイラーを作成している場合は、コンパイラーがどのように機能するかを十分に理解している必要があります。これはプロセスの一部ですから。

jQueryのような特定のフレームワークは、かなり抽象化されています。あなたは、ください必要、彼らが働いているかを正確に知っていますか？いいえ。しかし、ライブラリが何をしているのかをしっかりと基本的に理解することは、コードを書く際に非常に有益です。なぜなら、フレームワークがそのままである理由をよりよく理解し、それを最大限に活用できるからです。 。

私の経験では、ライブラリ依存を排除​​することはできないため、あなたとあなたのチームは問題を解決するのに十分な知識が必要です。

プログラマーとしての時間はほとんどないため、最も優先度の高いものを選択する必要があります。問題はできるだけ早く、穏やかに解決する必要があります。このことだけが、「物事のすべてについて機能することを学ぶ」ことをいくぶん冗長にします。

ここで追加したいのは「依存」です。コミュニティとして、私たちはすべて他者に依存しています。Java、.NET、APIなどのアプリケーションを構築するためにGiantsに依存しています。そして、Giantsの仕事について信頼しています。それは非常に多くの人々のために働くからです。フレームワークまたはAPIに問題がある場合、他の人がどこかに直面している可能性が高く、解決策/回避策があります。

ここでの唯一の問題：多分、どこかで、制限された基準で、ジャイアンツは崩壊しました。たとえば、一部のOSではフラッシュがサポートされていないため、フラッシュなしではできなかったことがたくさんあります。この可能性はゼロ以上ですが、この場合、できることはほとんどありません。これらの場合にのみ、「フードの背後にあるもの」に関する知識が有用であることがわかります。これは、問題が本当にどこにあるかを指摘し、大きな回避策を作成する可能性があるためです。しかし、投資する時間が本当に価値があるかはわかりません。

その可能性に対処するために、解決策があると思います：ほとんどのプログラマーはライブラリの「表面処理」を簡単にキャッチでき、非常によく理解している誰かが本当に必要な場合があるからです。各チームが1,2の有用なライブラリ/ツール/「スキルセット」について専門知識を持っているチームを構成しようとしています。jQueryについての優れた経験があり、データベースに特化しています。

別の観点はセキュリティです。正確な内部動作がわからないライブラリを使用する場合、正確に何が起こっているのかを推測します。失敗した仮定はそれぞれ、悪意のある攻撃者に対する攻撃ベクトルを開く可能性があります。

クイックソートを呼び出すときは、最悪の場合の振る舞いに注意する必要があります。そうでない場合、攻撃者は最悪のケースのデータを挿入し、DoSを実行できる可能性があります。

圧縮ライブラリを呼び出す場合、一部のデータがより少ないバイトに圧縮される場合、元のバイトよりも多くのバイトに「圧縮」されるデータが存在する必要があることに注意する必要があります。したがって、出力バッファーは[より少ないバイトに]圧縮するため、入力データのサイズのみが必要であると仮定すると、バッファーオーバーフローが発生するのを待っています。

あなたの仮定が真実であることを証明できるように、あなたがやろうとしていることについて十分な基礎を知っている必要があります。それ以外の場合、ライブラリは明示的にこれに注意する必要があります。たとえば、提供された出力バッファが十分に大きくないときに例外をスローします。

確実に機能する限り、使用するすべてを理解しなくてもかまいません。libのバグに噛まれたら、それがどのように機能するのか、なぜ機能するのか、なぜ機能しないのかを見てみましょう。もちろん、たとえあなたがそうする必要がないとしても、あなたは常にフードの下を見ることを歓迎され奨励されます。

プログラミングで難しいことの1つは、自分ですべての問題を解決する誘惑を克服することです。

大丈夫ですが、危険です。一般的な慣行として、彼が開発したものの働きを知る必要があります。

ちょっと...

ライブラリまたはフレームワークが何をしようとしているかの概要を把握していれば問題ありません。内部部品とそうでないものに関しては、いいえ。実用的なアプローチを取ります。うまくいき、私がやりたいことをやりました。

ポイントは、たくさんの小さな詳細で下にぶら下がるのではなく、すでにあなたのいまいましいアイデアを実装することです。

ポイントは、あなたがすべてを知るつもりはないことだと思います。真剣に、すべてを調査する時間はほとんどありません。なぜなら、あなたのアイデアを作成するというあなたの主な目標からあなたをそらすからです。少しずつ、おそらく、週末に自由時間を設けて、主題に関する章などを読むことができます。

ただし、自由な時間がない限り、すべてを把握しようとしないでください。このように見てください。プログラミング言語を使用する理由は、アセンブリコードを実行できないようにするためです。アセンブリコードを使用する理由は、1と0を実行できないようにするためです。その背後にあるメカニズムの詳細をすべて知る必要はないと思いますが、その概要を知っているだけです。ガベージコレクターのように、ポインター/メモリを処理することを知っています。魔法のようにきちんとしたアルゴリズムを使用するかどうかは気にしません。たぶんそれの短所だけど。もちろん、あなたがそれに対処しなければならない分野にいるのでなければ。それから、あなたはそれがあなたの仕事の一部であるので、とにかくこの質問をすることはないでしょう。