Konifar's WIP

親方！空からどらえもんが！

ライブラリの守備範囲は狭い方がいい

開発 思考整理 自分の指針

開発で使うライブラリってどう選定してますか？

たぶん選定基準は様々ですよね。社内で基準が明文化されてるところもあるかもしれません。

選定の際には、GitHubスターの数やドキュメントの充実度、最終更新日といった客観的な指標はもちろん、キャッチアップコストやサービスの規模といった開発上の様々なトレードオフを考慮する必要があります。自分は漠然と「ライブラリはあんまり大きくない方がいいなぁ」と考えていたんですが、ちゃんと思考整理できていなかったので、ざっとまとめておこうと思います。

Android開発が多いので、Androidのライブラリを例に話します。あくまで現在の自分の考えのまとめなので、それ違うんじゃない？と思われるところもあるかもしれませんが、その辺は優しくツッコミいただけると嬉しいです。

ライブラリはみんなの課題を解決する

そもそもなぜライブラリを使うかというと、その方が楽だからですね。最近はライブラリを組み合わせるだけで結構すごいアプリができちゃいます。車輪の再発明をしなくていいわけです。

特にネットワーク周りや画像処理といったよくある実装まわりはAwesomeなライブラリが充実しているので使わない手はないです。 みんなが悩みそうなところや苦労しそうなところを解決してくれるのがライブラリを使うメリットと言えるんじゃないかと思います。

解決する課題を明確にする

そう考えると、 解決する課題そのものがライブラリの価値を決めると思うんですね。

もちろんこの価値というのは絶対的なものではないです。例えば、自分はmortarやflowといった実装スタイルを変えるようなライブラリを見ると、「これ使って何が嬉しいんだろう…」と感じてしまうことがあります。ドキュメント読んでもコード読んでも、何のためにそんなことをしてるかイマイチぴんと来ませんでした。

これはライブラリの価値が低いというわけではなく、おそらく ライブラリの解決する課題に直面していないので実感がわかないだけだと思うんですよね。ユーティリティ系のライブラリも同様で、めんどくさいと感じていないと「普通に書けばいいんじゃ…」と思ってしまう。

つまり、そのライブラリが開発に役立つかどうか判断する時には、 現在もしくは未来に抱えそうな開発上の課題を明確にするのが大事じゃないかなと思うわけです。

例えば1つ例をあげてみる

Android-ObservableScrollViewというイケてるライブラリがあります。

github.com

様々なスクロール処理を簡単に実装できるライブラリです。

f:id:konifar:20150514174345p:plain

自分もこのライブラリ使ったことがあって、とても助けられました。メリットは、スクロールまわりの実装コストを抑えられるってところですね。超わかりやすいです。

ただ、このライブラリの解決するスクロールまわりの実装のサポートが、全てのアプリに有効かというと必ずしもそうじゃないわけです。

このライブラリは、ScrollView、WebView、ListView、RecyclerViewなど様々なViewに対応しています。実装のパターンもたくさん用意されています。

逆に言うと、パターンが1つでよくてListViewしか使ってないみたいなケースでは、このライブラリを使う必要はないと思うんですね。アプリサイズも余計に増えますし、dex問題も怖いです。アプリの性質やフェーズにもよりますが、自分で実装したほうがいいケースもあるということです。

開発する上での課題が何なのかを考えてみると、こういった判断がしやすいです。「一部WebViewで制御大変だし、やっぱりこのライブラリ使った方がよさそうだなぁ」みたいな感じですね。

ライブラリと依存の話

以前、@gfxさんのTweetに反応して、こんなやり取りをしたことがあります。

Fragmentのargまわりめんどくさいよねという話で、AndroidAnnotationsの話が出ました。AndroidAnnotationsは、これはこれでかなり便利なんですよね。

qiita.com

とりあえずこれ入れたら色々捗りそうだなぁとも思うわけです。

しかし、こんな意見もあります。

これはどういうことかというと、 「このライブラリなしじゃ生きていけなくなってしまうの怖くない？」という依存の話です。極論言うと、サポート切れた時にガッツリ使ってたら置き換えできるのか、みんな死ぬしかないじゃない！みたいなことにならないか、ということです。

もちろんスターの数や更新の頻度などである程度判断はできることもありますが、ライブラリを使うと多少なりとも実装に依存するので、そのあたりは注意が必要です。

ライブラリの守備範囲は小さい方がいい

で、依存のことを考えると、 あんまりマッチョなライブラリは怖いなぁと思っちゃうんですよね。

たくさんの課題を解決するライブラリってすごいし魅力的なんですけど、継続的に開発する場合はリスクが高いんじゃないかと感じるわけです。プロトタイプとかハッカソンで使うならいいかもしれないですが。

逆に、課題が明確に1つ決まっていて、シンプルにそれだけを解決してくれるライブラリは安心感あります。

わかりやすい例がButterKnifeです。

'View "injection" library for Android'

タグラインを見てもわかりますが、解決してくれる課題がすごく明確なんですよね。どう使えばいいかも迷わないし、依存も最低限で済むので、もし使えなくなったとしても修正のコストはそこまでかかりません。

特に名前の由来を知った時、なんてクールなライブラリなんだと思いました。

Dagger (短刀) はいろいろなことができる。切ったり刺したり削ったり

Butter knife (バターナイフ) はパンにバターを塗ることぐらいしかできない。が、パンにバターを塗るときにはとても便利

Android - Butter Knifeの紹介 - Qiita

名前って結構重要で、ライブラリの守備範囲を狭く保つのに役立ちます。AndroidQueryやAndroidAnnotationsのような、Android~みたいなふわっとした名前のものは、全般的に便利な反面、本来不要な機能もつけられてマッチョになりがちな気がします。

まとめ

「何でもできると便利だけど、それにガッツリ依存するのは怖い。ライブラリは守備範囲狭い方が安心感ある。」

これが自分のライブラリ選定の際の指針の1つになってます。もちろん評判とかも重要なんですが、最終的にはこの指針と照らし合わせて判断するようにしています。