ライブラリの選定方法について
2021-09-24 14:04:31 +0900
ライブラリを選定するうえで、どういう観点で気を付けているか?
ということを聞かれたので、本当に当たり前のことしか書いていないのだけど、ざっくりまとめておく。
ということを聞かれたので、本当に当たり前のことしか書いていないのだけど、ざっくりまとめておく。
GitHubのStar数、最終更新が1年以内
スターの数や期間は参考程度です。
本当にざっくりした数字なのだけど、スターが1000超えてて、
1年以内に更新していたりしたまぁ、だいたい大丈夫だよねいう感じ。
たとえ反映内容がREADMEの更新であったり、CIの設定変更の修正だったりだとしても、「ちゃんと見ているんだなぁ」というメッセージにはなるので、利用者としては安心して使えるというのもあるかなと思っています。
本当にざっくりした数字なのだけど、スターが1000超えてて、
1年以内に更新していたりしたまぁ、だいたい大丈夫だよねいう感じ。
たとえ反映内容がREADMEの更新であったり、CIの設定変更の修正だったりだとしても、「ちゃんと見ているんだなぁ」というメッセージにはなるので、利用者としては安心して使えるというのもあるかなと思っています。
今後破壊的更新が予定されていないか? もしくは許容できるか?
すでに枯れているライブラリでも、
今後関連するライブラリのバージョンアップや思想のアップデートによって大幅に破壊的変更が取り込まれることが予定されることもしばしば存在する。
なので、枯れているライブラリであっても油断しないで気になるIssueのトピックだったりを見逃さないようにしよう。
例えばVuexというVueでFluxパターンを実装するようなライブラリがコアチームからリリースされているのですが、
ここでFluxパターンをやめてしまうのではないか?、そしてその過程でという議論が進んでいるようでした。
といったように、枯れたライブラリでも思想や設計のアップデートによって大幅な変更を余儀なくされることもあるので、それに付き合っていけるような覚悟があるのか?はたまた過渡期で今は導入するべきではないのか?というのはケースバイケースでありますが、検討項目すべき項目の1つだと思っています。
今後関連するライブラリのバージョンアップや思想のアップデートによって大幅に破壊的変更が取り込まれることが予定されることもしばしば存在する。
なので、枯れているライブラリであっても油断しないで気になるIssueのトピックだったりを見逃さないようにしよう。
例えばVuexというVueでFluxパターンを実装するようなライブラリがコアチームからリリースされているのですが、
ここでFluxパターンをやめてしまうのではないか?、そしてその過程でという議論が進んでいるようでした。
Vuex 5のRFCをちゃんと読んでみた。
— Kawamata Ryo (@KawamataRyo) March 10, 2021
> Vuex 5 is almost completely new software compared to Vuex 3 & 4.
とRFCにも書いてある通りもはや別ライブラリ。
Fluxパターンをやめるので、APIの変更かなりある。
マイグレーションは大変そう。
↓ 以下の要点をスレッドにメモhttps://t.co/KmRpdY02X4
といったように、枯れたライブラリでも思想や設計のアップデートによって大幅な変更を余儀なくされることもあるので、それに付き合っていけるような覚悟があるのか?はたまた過渡期で今は導入するべきではないのか?というのはケースバイケースでありますが、検討項目すべき項目の1つだと思っています。
誰が作っているか? 注目しているか?
例えば、RubyやRailsだと、Rubyのコミッターでもあり、Railsの日本人コミッターであるamatsudaさんはRubyやRailsに関係するライブラリをたくさん公開していて、
なかでもKaminariはRailsでページネーションを実装する際には第一候補に挙がるであろうライブラリだと思う。
「ライブラリ職人」みたいな人はどの言語にいるものだったりするので、 職人をウォッチして、彼、彼女たちがリリースしたライブラリをいち早く試すのも面白いと思っている。
作っているかという観点だけでなく、誰が注目しているか、おすすめしているか。というのも重要な指標になり得ると思うので、ライブラリを導入するメリット、デメリット、両方の意見を取り込んで選定するのできるとよいですね。
なかでもKaminariはRailsでページネーションを実装する際には第一候補に挙がるであろうライブラリだと思う。
「ライブラリ職人」みたいな人はどの言語にいるものだったりするので、 職人をウォッチして、彼、彼女たちがリリースしたライブラリをいち早く試すのも面白いと思っている。
作っているかという観点だけでなく、誰が注目しているか、おすすめしているか。というのも重要な指標になり得ると思うので、ライブラリを導入するメリット、デメリット、両方の意見を取り込んで選定するのできるとよいですね。
上記を鑑みても不安な場合は自分でコードを読めそうか?
上記のことをひっくるめてちょっと不安だな、けど使いたいなという場合は、
自分で「深く」コードを読んでみたりして、「最悪自分がメンテする」という選択を「安易に取るべきではない選択」ではあるものの取っていいとは思っていますが、あくまでも最終手段ということで。
そのほか気を付ける点
- ライブラリが解決する課題を正しく理解する。
- Qittaなどの記事だけを盲目的に信頼しない。
- 特にQiitaだったりは誰が書いているか?というのを注意してみたほうが良い。
- 流行っているから、デファクトだからという理由だけで盲目的に導入するべきではない。
- 自分があまり詳しくない分野なら同僚や有識者に相談する。
- チームでプロダクトを作る場合、同僚につかえそうかをヒアリングする。
- そのWebAPIをラップしただけのSDKは本当に必要? 自分でクライアント書くほうが楽じゃないかを考えてみる。
- 自前で数行書けるなら、そのライブラリはインストールしないほうがよいかもしれません。
- 本格的に使い始める前にお試しで使い始めてみる
- 類似のライブラリが複数あって迷う場合は、使い比べもしてみていいと思う。