優れたプログラマになるためにライブラリを読むべきか

最初に

私は決して優れたプログラマではありませんが、多くの言語と多くの分野で半世紀以上、大型コンピュータ・スーパーコンピュータから、PC(NEC 8001)からの草分け時代、ワークステーション、スーパーミニコン、超並列コンピュータ、最近では、富岳や京コンピュータ、ネットは、パソコン通信と言われていた時代・インターネットは黎明期から今日に至るまで、主にシステム・科学技術系のプログラミングに従事してきました。　事務計算などや特殊なプログラミングを使用したニッチな分野での仕事もこなしてきました。
習得してる20種以上のプログラミング言語なかには、APLのように、ヒエログリフのような文字を使い、右から左に読む言語などもあります。

新しい言語でもほぼ一週間あれば、仕事に使えるくらいのブログラミングはできます。　実際は、３日以内と言うのが多かったです。　これが可能なのは、普段から数学と物理をはじめ多くの自然科学に関する研鑽をしており、多くのアルゴリズムの文献、コードを読んできたからです。　ページワンと言うトランプゲームがありますが、毎回ルールを変える変形ゲームがあり、それと同じようなものです。

また、第一級アマチュア無線技士の資格も持っており、ハードウェアに関しても、PCを組み立てるだけではなく、半田ごてを持ってある程度、対処できます。

ですから、初めて客先にいって、初めて見るコンピュータでも、何故かそこにいるエンジニアよりよく知っていたりして、驚かれます。　所詮、人が作るモノ、合理的なマシンの粋であるコンピュータの作りは余り大差ないのです。

ですから、ソフトウェアに関する新しい技術が出てきたときに、他の人と同時に情報を得ているのにも拘わらず、何故か、教える側に回ることが常です。

それらの経験からのお話しです。

私の結論

結論として先に書きますが、何の目的もなしにライブラリのソースコードを積極的に読む必要はないと思います。　私は必要に迫られて読まざるを得ませんでした。　しかしライブラリに限らず他人のコードを読む事は非常に参考になり無駄にはなりません。　1つ注意が要るのは、必ず何か実装したいことを明確に持って読むことです。　　なぜなら、やりたいことの目的があって読まないとモチベーションを保ち続けることができないからです。　　調査をすることにより、お金がもらえると言うのも立派なモチベーションになります。

背景

私は科学技術系のソフトウェアパッケージを主にC++17で開発しています。　　また、ほとんどのプログラミング言語でも開発経験があります。(詳しくはプロフィールに書いています)　　従いまして、いろんなライブラリやフレームワークに接する機会が多いです。

また別件で、スーパーコンピュータやアーキテクチャの違うCPUのコンピュータにコンパイラなどの言語システムやライブラリを移植するシステム寄りの仕事をやったり、また企業で社内開発されたプログラムの再構築・整備などを依頼され、エンドユーザ向けの仕事もしています。

ついでに、社員のプログラミング教育も頼まれることがあります。

ですから、ライブラリだけではなくいろんな人が作ったプログラムを読む機会が非常に多くあります。　有名なライブラリでも、ほとんどコメントやドキュメントがないプログラムは珍しくはありません。　なんとか正常に動いているが、開発者はとうの昔に退職していて改良とか機能追加ができないなど、依頼される理由は様々です。

システム寄りの仕事では、移植後のテストが通らないとか、パフォーマンスが悪いなどのトラブルがあったりすると、ライブラリの中身も調べなければなりません。

その時、ソースコードも含めてかなり突っ込んで読み込まないと原因がわからない場合もあります。

ライブラリを読んでみると...

まぁ、有名なライブラリに限って言及しても、その出来は千差万別ですね。

質問者の条件にある「洗練された他人のプログラム」で、洗練されているかどうかは読んでみないと分かりません。　　また、ライブラリは多数の人が関与して作っていますのでどうしても部分によって、その品質にバラツキがあります。

非常に洗練された素晴らしい実装をしているものもあれば、これはどこのど素人が作ったんだと言うものまであります。

優れた例にせよ、反面教師にせよ他人のコードを読むのは非常に勉強になります。

巨大なアプリケーションコード

若い頃はアメリカから輸入した巨大な原子力コードをCRAYと言うベクトル型のスーパーコンピュータに移植するするため、たくさんのソースコードを読みました。　ノーベル賞をもらった学者が作ったコードもありました。　参考にはなりますが、必ずしもその実装が優れたものではありませんでした。　たくさんのコードを見るとプログラマの癖やその優劣がだんだんわかってくるのです。

とにもかくにも、たくさんの他人のプログラムを読まされることになりましたが、それは今日の私の血となり肉となっています。

ライブラリの様々な実装

メジャーなライブラリとフレームワーク

ライブラリによっては非常に苦労されている跡が見えるものもたくさんあります。

例えばC++ならばオーバーロード・オーバーライドがありますが、別の言語でその仕様がない、もっと広範な動的呼び出しがしたい、パフォーマンスを上げたいと言うことで、ライブラリ中でその仕組みを実装しているものもあります。

少し例が古いですが、例えば、MFC、ATL、Qtなどのライブラリで、DDX、コマンドメッセージ、イベントやコールバック、シグナル、スロット、非同期処理などはそれぞれ独特のポリシーを持って実装されています。

これらはフレームワークの構成要素としてライブラリがあります。

ですから、フレームワークの作法とともに、ちゃんと理解して使わないとまともに動作しません。　幸いにして、詳しいドキュメントがあったとしても、結局ライブラリの中身を見て使うことが求められることが多いです。

科学技術系では

科学技術計算系では特定目的の計算のアプリケーションとしての総合ツールはありますが、既存のメジャーなプログラミングを対象としたコードベースが前提のフレームワークというものはあまり存在しません。

大次元マトリックスソルバのような科学技術ソフトのライブラリでも同じです。　数学的な理論はもちろんのこと、実装に使われているポリシーを理解しないとまともに使えません。　それには一番手っ取り早いのがソースコードを読むことです。　

ただし、数学ライブラリは50年以上前から、存在しており、そのアルゴリズムは良く知れ渡っています。　ですから、FORTRANなど古いプログラミング言語で作られたものが未だに使用されてる場合もあります。　いわゆる、枯れた技術でもあります。　この場合は、インターフェースを通じて使用する形をとることが多いです。　使い込まれた古いコードは信頼性が高いこともあるからです。　ただし、古いコードはメモリモデルが古いので、現代のコンピュータにマッチしてないこともあります。

グラフィックス・ライブラリ

科学技術計算系でも、シミュレーション結果のポスト処理である可視化、シミュレーションのジオメトリを作成するためのプリ処理におけるモデラーは、古くからOpenGLなどのライブラリで作成されていました。　MFCではGDI, GDI+ などですね。

私の、プログラミング人生の半分以上は、グラフィックス・ライブラリを使用して、3Dモデラーや可視化ツールを作るのに費やしました。　弊社、株式会社シフトロックで私が開発した、三次元非線形リアルタイム動磁場解析ソルバQm とその、モデラーであるPのグラフィックス部分は、GDIとOpenGLで開発したものです。

もちろん、AVS (汎用可視化ソフトウェア)などの優れた3Dグラフィックス・ライブラリもかなりデーブに使用したことがあります。　しかし、旧クボタコンピュータ から数社を経て、現 サイバネットシステム株式会社(磁場解析ソルバ開発メーカーにおいては弊社のライバル)に移ってしまいました。

最近の例

あるライブラリではCPUのエンディアンが違うと、汎用型の変数演算がおかしくなる実装もありました。

またJavaやRubyなどにあるガーベージコレクタによるパフォーマンス低下をいかに防ぐかとか。

Direct X の行列演算の高速化テクニックなどは非常に参考になりました。