読者です 読者をやめる 読者になる 読者になる

頭の中は異空間

生活を日々ハックしてよりよくするブログ

ライブラリを組み込むべきかどうかの判断基準について

どうも。

 

便利だけど学習コストが気になるライブラリ、調べれば調べるほどたくさん出てきます。これだけ多くいろんな人が作ってくれたのかと思うと便利だし使いたくなってくるんだけど、実際組み込んでみてから実は自分のサービスに不都合だったり、ちょっとした導入部分でつまづいてやる気失せたり..必ず何らかの壁が立ちはだかってくるものですね.

そこで導入するかどうかの判断基準を自分なりに考えてみました。

 


学習コスト

一番はこれ。自分一人で開発するならまだいいけど、チーム単位でってなってくるとその全員が使いこなすのに難が出るのはちょっと。。となると思います。

ライブラリのソースやドキュメントを読み込む頻度があまりに多いと開発がスムーズに進まないんじゃないかな?

すでにQiitaなどに使ってみた、とか初心者向け、とかノウハウが固まっているものが多いとはいえ、開発までにあまりに手間がかかるものはどうかと。しかもライブラリは使わないところでは全く使わないから、せっかく学習しても他所で応用が利かないと、学習する側もちょっと面白くないかも。

 

特殊な文法を使うもの

RailsでいうSlimやMongoDB、jsでいうcoffeescriptなど。それ自体の文法を別で覚える必要があります。だから、そこまで身につける価値があると思えば使えばいいし、苦労して導入した割にサイトのパフォーマンスやエンジニアの開発効率が上がっていないなら、ちょっと勿体ない。

導入する前にメリット・デメリットを知ったり、他の似たライブラリと比べて(jsでいうbackbone、vue, angular, reactなど)どれが自分のサービスに合うのか、場合によっては実際に使ってプロトタイプを作って感覚を確かめるなど。

特別な書き方をすることでかえって元言語よりわかりやすくなるならある意味、リファクタリングになると思うので導入する価値はありそう。

ただ、あまりに基本とする文法から外れすぎたり特殊な設定ファイルが必要だったりすると学習コスト高くなるかもしれない。。

そして、後でやっぱりこのライブラリから別なのにしよう、なんてしても実はそのライブラリへの依存度が高すぎて、別のを導入するにはviewから何から丸ごと修正が必要になったらどうでしょう?そういう意味でも後々の学習コストや開発コストに関わることも考えて選んだほうが良さそう。。

 

そのライブラリの人気

これは周りの環境に依存してる気がするけど、判断基準として考えています。

人気のあるライブラリなら既に誰かが使っていてドキュメント以上にわかりやすいビギナーのためのメモを残してくれているかもしれないし、業界でも使われていて自分の独学や前の会社で使っていた知識がそのまま活かせるかもしれないし。

それに多くのエンジニアに使われているならその分ライブラリへのコミッタも増えやすいし、ダメな点があれば製作者へのフィードバックもあるはず。そうして洗練されたライブラリなら、大事なサービスに導入する価値は非常に高いと思います。

 

そのライブラリはメンテされているか?

もし作られたけどそのまま投げっぱなしになっていたら入れたいとは思いません。

言語のバージョンが上がるにつれて当然、syntax上の問題やライブラリ内部で呼んでいるメソッドの挙動なども変わってくる。

とすると、もし更新がないなら、後々そのライブラリが使えなくなる可能性は高いので、それに合わせて(もしくはもっと頻繁に)更新がなされるべきだし、自分のサービスの依存度が高くて、ライブラリのせいで逆にサービスが成り立たなくなるなら色々アウトだと思います。

もしGithub上にあるなら、そのコミット履歴を見ればどれくらいの頻度でいじられているかがわかります。

 

ライブラリの目的

それが一体何のために作られたのか、設計思想がわかるはず。たとえばライブラリではないけどよくあるDBの比較で、SQLiteなのかPostgreSQLなのかMySQLなのかDerbyなのか。

単に名前や使い方を身につけるんじゃなくて、それが何を解決するために作られたのかを理解すると、自分のサービスに合っているかもわかるし、相性が良くないなら後で取っ替えるなりすれば良い。

 

逆に考えるんだ。自作しちゃえばいいさと。

 もし自分にふさわしいものがないなら、いっその事自作するのも手。幸い、参考になる製品はすでに世の中にあるのですから、0から1を生み出すよりはずっと楽なはず。

 

 選択肢が増えすぎるとかえって迷いすぎて先に進めないというジレンマ。。