プログラミングをするとき、ライブラリを使うことがあると思います。ライブラリを使うときに、なにかしらの条件をもとに『そのライブラリを使っていいかどうか』を考えたりします。
自分の中で、このライブラリの選定基準をうまく言語化できてなかったので、自分なりにまとめてみました。
この記事では、プログラミングにおけるライブラリの選定基準とはなにか、選定基準をつくるべき理由と選定基準について書いていきます。
この記事でいうライブラリの選定基準とは、ライブラリを使おうとするときにそのライブラリを使っていいかどうかを判断するための基準のことをいいます。たとえば『メンテナンスされているか』などが基準としてあります。
ライブラリの選定基準をつくる一番の理由は、プログラムのメンテナンス性を保つためです。導入すべきでないライブラリを選んでしまうと、破壊的な変更が多くて追従が大変だったり、バグが放置されてモンキーパッチをあてることになったりしてしまいます。
個人・チームに関わらず、プログラミングをするときに基準をもっておくべきだと思っています。
選定基準をつくる理由については、メンテナンスの問題以外にも、パフォーマンスへの影響や法的リスクの検証といったものもあります。
まずライブラリの選定基準を表でまとめつつ、次の章でそれぞれについて書いていきます。基本的にはどれも満たすべき項目だと思っています。逆に満たしていない、満たせない項目については、そこがリスクになることを把握しておいた方がよさそうです。
番号 | 項目 |
---|---|
1 | メンテナンスされているか |
2 | 破壊的な変更は多くないか |
3 | 使われているか |
4 | リリースされてから十分な時間が経過しているか |
5 | 安定版か |
6 | 依存関係は問題ないか |
7 | アプリケーションと疎結合にできるか |
8 | テストは十分か |
9 | 守備範囲が広すぎないか |
10 | 学習コストは高くないか |
11 | ドキュメントは充実しているか |
12 | 遅くないか |
13 | ブラックボックスなところはないか |
14 | 使えなくなったときの代替案はあるか |
15 | ライセンス上の問題はないか |
ひとつひとつ見ていきます。
コミットログの頻度や、Issues/Pull Requestsの対応状況を見てみます。コミットの頻度が少なかったりバグが放置されていたりすると、モンキーパッチなどで対応することになるかもしれません。
GitHubなら、開発者の方の草の生え具合を見てみるのもいいかもしれません。
CHANGELOGを見てみます。破壊的な変更が多いと、追随するためのコストが高くなるリスクがあります。
ライブラリが使われているかどうかで、開発者の方のそのライブラリに対するモチベーションを推測することができます。GitHubならスター数などが参考になると思います。
リリースして間もないライブラリだと、将来の変更が見えづらいという問題があります。
ライブラリが安定版でないと、破壊的な変更が入ったり、既知のバグがあったりします。バージョンが1.0以上であればいいかというとそういうわけではなく、ライブラリによってバージョニングの方針が異なるので、READMEなどを確認してみます。
依存関係が多いと、ライブラリのバージョン管理が難しくなります。ライブラリ自体が依存しているライブラリのメンテナンス状況なども同様に見ておく方がよさそうです。
ライブラリがアプリケーションと密になってしまうと、そのライブラリの変更に対する影響を大きく受けてしまうことになります。また、ライブラリの使用をやめる ときのコストも高くなってしまいます。
必要なテストが書かれているか、また自動化されたテストをパスしているかを確認します。
『ライブラリの守備範囲は狭い方がいい』という記事にもありますが、守備範囲が広いとアプリケーションのサイズが大きくなったり、代替が効きづらいという問題につながってしまいます。
独自DSLなど、ライブラリを使うための学習にかかる時間が多いと、チーム開発でパフォーマンスが下がるかもしれません。汎用性のない知識の習得は、人によってはたのしくないと思うかもしれません。
インストールや使用方法、APIなどの情報が最低限まとまっているか、古い情報が残ったままになっていないかなどを見てみます。
用途としては問題ないけど遅い、というライブラリがあったりします。パフォーマンスが重要なところに導入するライブラリではとくに注意した方がよさそうです。
ベンダー製のライブラリでは、本質的なロジックをAPI経由で処理したりします。仕方のないことではありますが、リスクとして把握しておいた方がよさそうです。
ライブラリがメンテナンスされなくなったり、思想が変わってしまうことがあったりします。そのときの代替案を想定しておくことは重要な観点だと思います。
ライブラリのライセンスが導入するプログラムにとって問題がないかを確認します。『Facebookの特許条項付きBSDライセンスが炎上している件について』にあるような、ライセンス上の問題に発展するリスクがあります。
ライブラリに選定基準をつくっておくことで、継続的にメンテナンス性を保つことにつながります。ライブラリを使うときは、基準にそって判断し、基準を満たさないものはリスクとして把握しておくとよさそうです。
Webエンジニア&プロダクトマネージャ。 プログラミングで『ひとりで働く』を模索中。 三重の山の中で妻とこども、ネコとのんびり暮らしています。
Follow @zenizhWebエンジニア&プロダクトマネージャ。 プログラミングで『ひとりで働く』を模索中。 三重の山の中で妻とこども、ネコとのんびり暮らしています。
Follow @zenizh共著で『現場で使えるRuby on Rails 5(マイナビ出版)』を書きました。
Amazonでみる