ひきぷろのプログラミング日記

プログラミングの日記です。

ライブラリの分類について

ライブラリを作る時に、今、自分がどこの部分をターゲットにして作っているかということを明確にする分類表を見たことがないので、個人的に分類してみたいと思います。なんとなく、検索していたら必要なインターフェイスを見つけることができたり、これは無くてはならないので外せない要素だと感じたり、というようなことは調べていくと必然的に繋がっていくものではあります。しかし、自分が今、どのような分類に当たるライブラリを作り始めているのか?という、今向かっている方向について、自覚的に位置づけするような考え方がプログラマ全体として共有されていないように思います。つまり、コンパスと地図無しで自分の位置を直感で知り、向かう方向を経験によって決めていくというような、職人芸的な要素をそこに見つけてしまった感じです。これは誰かが言語化しておかないといけないと思いました。今から書くことは、ボンヤリしているような内容になるかもしれませんが、誰かがさらに具体化していってくれたら良いなという思いもあります。

ライブラリの分類とは

ライブラリには色んな種類があります。あるプログラミング言語の基礎部分を拡張するもの、ある環境間の差異を吸収するもの、あるファイル形式を簡単に扱うことができるようにするもの等です。これらについて、何らかの考え方で分類する方法があった方が良いのでは?と考えています。生物について検索しているときに、〇〇属〇〇科のように分類が付いていたりすることがありますが、同じ種類の分類表がコンピュータのライブラリについても必要なのではないかというような発想です。

分類する時の特徴

しかし、何をもって分類すれば良いのか?特徴をどこに見つけるのか?という疑問が必然的に出てきます。分類する時の特徴となりそうなものを少し挙げてみます。

  • ライブラリが実行可能な環境
    • コンピュータの種類
    • OS
    • 言語
  • ライブラリの依存関係
  • ライブラリの分野
  • 抽象度
  • コードの複雑さ

Linux のパッケージ管理ツールでは、上に挙げた「ライブラリが実行可能な環境」と、「ベースとなるライブラリの情報」についてはデータ化されてまとめられていて、有効に活用されています。他の点について、説明テキストだけではなく、コンピュータで処理可能な形でデータ化できるのではないか?というのも解決したいと考えています。

ライブラリの分野についても、木構造化されていて、グラフィカルな方のパッケージ管理ツールを使うと分類が分かりやすくなっています。

パッケージ管理ツールで見やすくはなっていない部分について考えてみると、外部インターフェイスと抽象度については簡単に確認する方法がなさそうかなと思っています。ベースとなるライブラリを調べることで、外部インターフェイスについて、おおまかに知ることはできます。さらにもう一段階見やすく分類するために、マインドマップUML のような方法で外部インターフェイスマップを描くことができそうだと考えています。

抽象度というのは説明しにくい考え方ですが、順番に書いていきます。抽象的にコードを書くと必然的に外部インターフェイスが狭まるという特徴が表れると個人的には考えています。外部インターフェイスを明らかにすることで、どの程度のインターフェイス数、関数の数で外部コードと接続されているかが同時に明確になります。その、インターフェイスの種類、数等によって、どの程度抽象的なのかを数値化することができるのではないかという発想で抽象度と表現しました。抽象度が高いライブラリは、インターフェイスの種類と数が 0 に近い値になると考えています。抽象度が低いライブラリは、色んなインターフェイスと繋がるため、数値は大きくなるのではないかと思います。ただし、インターフェイスの接続方法をさらに 2 種類程度に分類しないと、インターフェイスの接続数は多いが実際には抽象度が高いというような状態になるのではないかと今のところ考えています。

外部インターフェイスに基づいたマッピング

外部インターフェイスに基づいたマッピング方法はどのようになるか考えてみます。次のような描き方だと、分かりやすいマップが作れるのではないかと思います。

  • 四角形の中にライブラリ名を書く
  • 線でライブラリ間を繋ぐ
  • 線にインターフェイス名を書く
  • インターフェイス名の横に、使われている関数の種類を数値で書く
  • 関数の数に応じて線の太さを描き分ける

こうすると、繋がりが強いインターフェイスは太い線で描かれ、繋がりが弱いインターフェイスは細い線で描き分けることができそうです。

この描き方で、改善できそうな点については、

  • ライブラリ名のところに他の情報が追記できるかもしれない
  • 線の太さは、コードの密着度のような考え方で変えた方が良いかもしれない
  • 線の太さではなく、色で描き分けた方が良いかもしれない

というようなことがあります。
実際にこのマップが描けるアプリを作った後で、調整していくくらいの発想の方が良さそうな気もします。

このマップがあると何が便利なのか

このマップがあると、全体を俯瞰することができるということがまず便利な点として 1 つあります。Linux のパッケージを管理している人たちと同じような視点を誰でも得られるのではないかというような感じです。その人たちと同じ視点を得られた時に何が良いのかというと、ここのインターフェイスに繋がれるライブラリは数として少なくないか?とか、ここは繋がりすぎで、もうちょっとシンプルにした方がコンパイルしやすいのではないか?とか、そういう発想が手に取るように分かりそうだと考えています。

それらの発想を元にして、ここら辺がきちんと作られていない気がするから、そのプロジェクトを手伝いに行こうとか、このインターフェイスは有効に活用されていないから、新規プロジェクトを立ち上げようとか、次のアクションを起こすための手がかりが得られそうだというのが、大きなところだと考えています。

ツール支援によるヒント提示

また、ツールを活用することで、外部インターフェイスと抽象度について何らかのヒントが得られるのではないかということもあります。今作っているライブラリは、同じ分野の平均的なライブラリと比べてインターフェイスの接続数が多すぎるとか、抽象度をもっと高めた方がダウンロードされる数が増えるとか、移植性が上がるとか、自分で深く掘り下げなくても自動的にそういった、新たな視点ができることによって集められる情報が増えそうだと考えています。

また何か思いついたら書き足します。