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