ライブラリを導入する時に気をつけてること

仕事のプロジェクトでも個人の開発でも、新しいライブラリを導入する際に気をつけてることって人それぞれあると思います。

個人的にライブラリを導入する際に気をつけてること(基準的なこと)をまとめてみました。

私はAndroidアプリを開発してるので、いくつかはAndroidのライブラリを導入する際に気をつけていることが書かれています。

でも、他の言語やOSS等でもこのへんの基準って変わらないかなーと思ってます。

ライブラリの開発が活発化どうか

ライブラリがイケてるかどうかも重要なんだけど、最近はまずはこれを見るようにしてる。

活発化どうかを見極める基準として、以下のようなものを見てます。

• 最終Commit日(masterに対する)

• コントリビューターの数

• ライブラリのUpdateの間隔

• issueやPull Requestの数

あとは、以下のようなことも見ておくとライブラリがどれくらいオープンに開発されているかどうかもわかるかなーと思います。

• Contributeの方法がREADME等に書かれているか

• Gitterが用意されているか

ライブラリではないんですが、TypeScriptのGithubを見ると、Gitterがあったり、Travisのbuild状態が見えたりします。Contributeの方法も書かれてます。

これだけでも「活発そうだなー」という印象を感じます。

ライブラリの導入コストはどれくらいか

これは主にチーム開発をする際に、気をつけていることです。

ライブラリを導入したら、できればチーム全員に使った欲しいですよね。

でも、これって結構難しい課題だと思ってます。

学習コストや他のライブラリとの親和性などを考えないといけないと思います。

チーム開発で新しいライブラリを導入する際に、ライブラリを入れたい！と言った人の「自己満足」で終わらないよう気をつけたいですね。

個人開発でも学習コストや他のライブラリとの親和性という問題は同じだと思います。

あと、ライブラリの導入方法が書かれているかも重要ですね。

最近のAndroidのライブラリなら、GradleとMavenでの導入方法が書かれているのが一般的です。

ライブラリを導入して、どんな課題・問題を解決したいのか

これ大事。大事だよね。

こんな経験、私にはあります。

私 < 「このライブラリ、**最近人気あるみたいだから導入しない？**てか、もう導入した。」

チームメンバー < 「導入するはいいけど、それ入れてどんな課題や問題が解決するの？」

私 < ...(´・ω・`)

そう、これ。まさにこれ！！

この**「それ入れてどんな課題や問題が解決するの？」**が重要なんです。

いや、そんなこと言われなくてもわかっていると思うんですが、やっぱりいいライブラリがあるとこれを忘れがちな時もあります。

まさに**「目的と手段」が逆になってる**パターンです。

「手段」である**ライブラリの導入が「目的」**になってしまって、本来の「目的」が達成されていないわけです。

もはや上の私の経験パターンだと、本来の「目的」などないわけです。

これはとても良くないことだと思ってます。

常にライブラリを導入する前に、解決したい課題・問題があるはずです。

コード量が多いとかコードが複雑になってるとか。

Androidならデザイナーさんが提示してきたUIを自分で作るのは辛い。ライブラリないかなーという話です。

**ライブラリを導入したけど、状況が何も変わってない。**という結果は避けたいですよね。

READMEやWikiにライブラリの使い方がまとまっているか + サンプルコードがあるか

ライブラリでどんなことができるのかって重要ですよね。

AndroidのViewのライブラリなら、どんな見た目や動きをするのか

Logic関連のライブラリなら、どんな感じで書くのか + それを使ってどれだけコードがスッキリするか

みたいなことってパッと見でわかるようになってると、そのライブラリを採用するかどうか判断しやすくなると思います。

READMEにRepository名しか書いてない、Wikiにも何も書いてない、サンプルコードもない・・・という感じだと困りますよね。

REDMEに軽く使い方を書いておいて、詳細はGithub Pagesを用意して、そちらに書くみたいなパターンありますね。

Wikiに書いてもいいのですが、Github Pagesや独自のサイトを作っているライブラリはページの見た目も良かったりして、導入してみたいなーという気持ちが個人的には高まります。

ライブラリに問題(バグとか)があった場合に自分達でも対応できるかどうか

要はライブラリにバグがあって、そのバグのissueがまだあがってない、みたいな状況ってあると思います。

そんな時にライブラリのコードを読んでバグを直すことが自分達で可能かどうかって大事かなーと思ってます。

実際にちょっと前にAndroidでとあるUI ライブラリを採用した時に、issueにあがっていないバグを見つけてしまいました。

その時はなんとかバグの原因を突き止めてPull Requestを出すところまでできました。

もし、「コード量多すぎてわかりません！」というレベルのライブラリだったら、そのまま諦めていたと思います。

なので、ライブラリを採用する際に見れる範囲でコードにざっくり目を通すといいと思います。

例えば、私は以下のようなことを見てます。

• クラスがいくつあるのか ( 読める範囲かなー )

• どんな感じでコードが書かれているか ( 抽象化具合とか気になる )

• コードを見てなんとなくやっていることが理解できるか ( あーこうやってやってるのね！ )

ライブラリのコードに目を通すことは、無駄なことではないし、新しい学びもあります。

いいライブラリも導入できて、その中でどんなことをやっているのかが分かれば、一石二鳥です！

いいライブラリのコードを読み、そこから実装の技術を学ぶことで自分でライブラリを作ったりできます。

ライセンスが書かれているか

仕事のプロジェクトでライブラリを採用する際には、ライセンスは特にチェックした方がいい点です。

まず、ライセンスが書かれていないものは仕事のプロジェクトでは採用できないです。個人の開発でもためらいます。

なので、まずライセンスが書かれているかを見て、次にどんなライセンスを採用してるのかをチェックしてます。

issueやPull Requestにしっかり対応しているかどうか

これは主にライブラリがGithubみたいなオープンな場で開発されている場合に見ている点です。

ライブラリの作成者やコントリビューターが、issueやPull Requestに対して、しっかり反応しているかどうかを見てます。

Pull Requestはどれだけ取り込まれているのかとかチェックしてます。

さいごに

長々書いてしまいましたが、こんな感じでライブラリ一つ導入するにも考えることっていっぱいあるよねーという話でした。