俺的ライブラリとかフレームワークを採用するときの判断基準

できれば、なるべくコーディングしないで、もっとイケてる人が作ったものを使って済ませたい。そんなぼくは何をするにもライブラリを探すところから始めるんだけど、「採用したはいいけど、バグだらけで直される様子もない」みたいな状況にならないよう、気にしていることを列挙。

• 利用実績
  • Facebookとか、ワールドワイドなサービスが利用してます！とか書いてあると非常にポイントが高い。ただ、ライブラリ側に採用サービスとか企業の名前があったとしても、今現在も使っているとは限らないので、逆方向のチェックもしておきたい。
• 活動状況
  • Githubなどでホストされているものは、コミッタの数やコミットの頻度、Issueのオープン・クローズの状況を確認する。未クローズのIssueが多くてコミット頻度の低いものなどは要注意。ただ、Issueの内容は要望など、バグだけとはかぎらないのでその辺も留意。また、粒度の小さいライブラリだと、作った時点でほぼ完璧というものもあるので、そのへんも加味して評価する。
• StackoverFlow
  • StackoverFlowに限らなくていいんだけど、要はネットでの情報がどれだけあるか、というのは重要。ググってSOのリンクがバーっと出てくるようだったらまあだいたいOK的な。まあ、でもSOでネタにならないようなものはやっぱり要注意ですよ。ちなみにRails絡みだとRailsCastで扱われてると安心感が高い気になるけど、割りとすぐ廃れたりするものもよくネタになっているのであまりあてにならない。
• 機能サイズ
  • 見つけたライブラリに、使いたい機能は含まれているんだけどその１０倍くらい他の機能も含まれている。そんな場合は、学習コストが高くなりがちなので避けるようにしている。
• 使うところの重要性
  • ここまで挙げてきたポイントで評価したさい、あまり芳しい結果じゃなかったとしても、「まぁ、ダメだったらそのときに使うのやめればいいか」と思える範囲だったら人柱になってみるのもアリだと思う。すごく小さい内容ものはソースをチラッとみて「まあ、これくらいだったらバグってたり機能が足りなかったりしても自分で治すなり、機能を足すなりできるかな」とかもある。逆にそれなりにでかくて、コアな部分に使うようなものはそうとう慎重に行く。
• 競合プロダクト
  • マッチするプロダクトが見つかったとしても、興奮してそこで終わってはいけない。意外ともっとマッチするライブラリがあったりするので。僕的にはCompassを採用した２日後くらいにBourbonに切り替えたことは今ではいい思い出です。

他にもポイントあった気がするけど、まあとりあえず。