Clever Geek Handbook

使用するライブラリのコードを読む必要がありますか？

私たちが住んでいるなんて素晴らしい時間です！ あなたはプログラムを書いており、何かのためのライブラリが必要です-あなたは間違いなくそれを見つけるでしょう！ 多くのライブラリはオープンソースにあり、LGPLのような快適なライセンスの下で配布され、取り上げられ、問題を解決しました。 ビジネス：接続方法はreadmeで説明されており、ライブラリは美しいインターフェイスを提供し、デモがあります（コンパイルして動作します）。 一般に、内部データの抽象化、インターフェース、カプセル化のすべてのアイデアを備えたOOPは強力なものです（ ここでは皮肉がありません ）。



しかし、「抽象化」が始まる場所と時期について考えてみましょう。 たとえば、私は週に一度スーパーマーケットに行く車を持っています。 この場合、私にとっては、「ステアリングホイール、3つのペダル、1組のレバー」のレベルをかなり抽象化したものであり、必要な機能を提供しています。 そして、エンジンやマジックノームなど、ボンネットの下にあるものについては何も考えずに、ガソリンとスピニングホイールを飲んでいるので、何年も使用できます。 しかし、自動車整備士、自動車デザイナー、または単にプロのドライバーとして働いている場合、その内部構造が私の仕事であることを知るために、車を「ダウン」することはもうできません。 店で牛乳を購入する人は生きた牛を見ることはないかもしれませんが、この牛を飼育している農夫は、自分の健康\メンテナンス\栄養\ケア\搾乳に関するすべてを知る義務があります。 まあ、など 製品の「ユーザー」とその「作成者」には明確な区分があります。 前者は詳細について考えないことを許可するかもしれませんが、後者はそうしないかもしれません。





この場所まで読んだ場合、あなたはプログラマーである可能性が高いです。 繰り返しますが、あなたはコンピュータープログラムの作成に専門的に携わっている人です。 おそらく、彼の仕事に責任を負っており、おそらく自分自身を優れた専門家と考えています。 そして、あなたは他の誰かのライブラリを取り、そのインターフェイスのレベルでそれを熟知して、あなたの製品でそれを使用することが可能であると考えますか？





行動の曖昧さ


身元不明言語でのこのような抽象ライブラリのインターフェースを想像してみましょう： 



interface IInterface { bool Init(); int Calculate(int val); void Release(); }


すべてが明確ですよね？ Init（）を呼び出し、Calculate（）に何かを転送し、答えを受け取り、Release（）を呼び出します。



小学校？ 時間をかけてください。 次の場合に何が起こるか答えてください。

  1. Init（）を2回呼び出しますか？ そして1000回？
  2. Init（）を呼び出さずにCalculate（）を呼び出しますか？
  3. Release（）を呼び出さないでください？ そして、あなたが二度電話したら？ そして1000回なら？ しかし、Init（）を呼び出す前にどうでしょうか？
  4. 異なるスレッドからInit（）、Calculate（）、Release（）を呼び出しますか？
  5. 一般にval引数の範囲は何ですか？ 全整数？ そして正確に？ そして0も？ MIN_INTとMAX_INTはどうですか？
  6. そして、いくつかの例外がスローされますか？
  7. ここにログが書き込まれていますか？ それは何らかの形で構成されていますか？


まあ、など



あなたはこれらのことをドキュメントに記載すべきだと言いますか？ はい、そうでなければなりません。 しかし、最初に、これは常にそうではありません。 次に、ドキュメントは、コンパイラによって解析されず、実行時に実行されず、誰によっても自動的に検証されない文字のセットです。 真実があるかもしれません。 あるいは、タイプライターのサルの群れをノックした結果かもしれません。 または火星の天気。 開発者はドキュメントを書くことを好みませんが、それを更新することすら好みません。 それに対処する。 さて、または最後に、ライブラリコードを読んでください。



図書館の目的


だから、あなたはライブラリに「私が必要としているように見える」関数を見つけました。 時間をかけてください。 作成者が作成した理由と方法はわかりません。 必要な入力データのすべてのセット、必要なすべてのプラットフォームで、必要なパフォーマンスで副作用なしに機能することを保証するものはありません。 現在のところ、あなたが持っているのは、関数の名前と、あなたが個人的に見たことがない人からのいくつかの言葉です。



テスト


すぐにニュアンスの完全なセットがあります。 ライブラリにテストが含まれている場合、それは多くのことを言っており、読み取り、実行できるため、このライブラリの使用方法/使用方法についての理解が大幅に追加されます。 たとえば、「TODO：...」、「可能性のあるバグ」、「機能を実装した後コメント解除」とマークされたテストのコメント行など、テストでよく見かけます。 最も基本的なテストでさえ、たとえば、関数の入力時にケルビンの温度が予想されることを突然発見する場合がありますが、摂氏である必要があることは100％確信しています。



テストがない場合、これは多くのことを言っています（まず、別のライブラリを探す方が良いでしょう）。 おそらく、自分で作成する必要があります。 そしておそらく、ライブラリは、それらを書くのが非常に難しいような方法で書かれている-そして、ライブラリを使用する際に問題があるかもしれない。



ライブラリ作成者の資格




正確に2つのオプションがあります。 高い確率で、ライブラリの作成者は、ライブラリによって解決されるタスクの分野であなたよりも資格がありました。 そうでなければ、そうでなければ、彼は図書館を書くことを引き受けたでしょう。 これは彼のコードを読むための非常に重要な理由です-おそらくあなたは何かを学ぶでしょう、おそらくコードはあなたが知っているのに役立つか、あなたが予想よりも良い解決策を提供する解決された問題のいくつかの「落とし穴」を示すかもしれません。 いずれにせよ、優秀な専門家のコードを読むことは常に役立ちます。



2番目の（あまり一般的ではない）ケースは、ライブラリの作成者の資格があなたより低い場合です。 まず、これを理解するのは良いことです（そして、コードを読まずにそれを行う方法は？）。 第二に、これはチェーンのようなものです-あなたの製品の品質は最悪のコンポーネントの品質よりも高くなることはありません、そしてあなたは意識的に自分のために問題を作成したいと思いますか？



過失


あなたは、ライブラリを書いた人がどれだけそれを高品質にしたかったのか分かりません。 おそらく彼はコードを「研磨」するのに余分な100時間を費やしたか、恐らくこのライブラリは彼の最後の職場で彼の最後の製品であり、嫌われた雇用主を去る前の「最後の2週間」の間に書かれたのかもしれません。 最初と2番目のケースでコードの品質がどれほど異なるか想像できますか？



悪意


私たちは皆、乱数ジェネレーターで最近のNSAブックマークのストーリーを知っています 。 まあ、噂について（または噂ではない）についても、このケースで約1,000万ドルです。 人々は日常生活において非常に懐疑的で疑念を抱いていますが、ソフトウェアへの信頼という点では（そして突然自由になったとしても！）彼らは完全に反対の立場を取ります。



あなたの友達が誰か教えてください


製品とそのライブラリの関係についても同じことが言えます。 ライブラリにバグがある場合は、製品にバグがあります。 ライブラリのメモリリーク？ いいえ、現在これは製品のメモリリークです。 ロック？ パフォーマンスの問題？ 未定義の動作？ 受信、サイン。



おわりに



抽象化とは、何かの内部構造を理解していないときではなく、そのことを十分に確信しているときであり、それについて考える必要はありません。


More articles:


All Articles