本をよく読むエンジニアであれば、ライブラリの導入には慎重になるべきだということは共通の認識になっていると思う。しかし、どういったライブラリを導入すべきかという選定基準は自分の中ではまだ言語化できてないことに最近気がついた。絶対的な基準を設けるのではなく、ある程度柔軟に考えるべきだと思うが、自分がどう考えて選定するかを考えてみる。
品質
テストが書かれているか
自分のプロダクトでテストを書いているのであれば、ライブラリにもテストを求めるべき
長い間継続してメンテナンスされている（いた）か
急に出てきてセンセーショナルな売り文句で注目を浴びるライブラリは怪しむべき
コードの品質は悪くないか
導入する前にライブラリのコードは読むべき
効果
その後の実装効率をどれだけ上げるか
導入しない場合と大して変わらないのであれば不要
自分でそれを書いた場合と比べてどうか
短時間で同じようなものを書けるのであれば不要
管理できるかどうか
プロダクトの広範囲に依存をばらまくような API になっていないか
そのライブラリのバージョンアップが起きた場合どうするか
そのライブラリが依存するライブラリのバージョンアップが起きた場合どうするか
vue-xxx 系の UI ライブラリは Vue のバージョンアップで使い物にならなくなるリスクがある
たいていこのケースに直面すると作者がもうメンテナンスをやめている
採用を考えているライブラリが依存を持っているだけで採用を躊躇する
vue-xxx みたいなライブラリは xxx というライブラリのラッパーみたいなケースがかなりあって、それなら xxx のラッパーを自分で書いたほうが快適なケースがほとんど
ただ、xxx ライブラリの作者が vue-xxx も提供してるケースは悪くない
いくつかの組織を見てきた印象では、世の中のエンジニアの多くは割と気軽にライブラリを導入しがちに見える。最近、なぜライブラリを使わないのかと聞かれた時に、「ライブラリを使うということは、このプロダクトの命の一部をライブラリに差し出すことと同じ」という話をした。100個のライブラリに依存すれば、100人の無関係な他人にプロダクトの命を預けているのである。個人的に、ライブラリの選定はそれほど重いことだと思っている。ライブラリを導入するデメリットは結構ある。
自分でコントロールできない
ライブラリの新しいバージョンがリリースされた時、バージョンアップのプレッシャーがかかる
上げるだけですむなら良いが、追加の作業が必要なケースもある。
放置することにしたとしても、他のライブラリのバージョンアップを妨げるケースもある
プロダクト用に新しい機能がほしい時、ライブラリの作者が取り入れてくれない場合がある
機能が汎用的でない場合
作者やライブラリの方針と合わない場合
そもそもメンテナンスがされていない場合
自分で書けばプロダクトに最適化できるし、反映は即時である
無駄な実装が入る
得てしてライブラリというものは汎用的な実装がされるので、自分が使わない機能もプロダクトのコードに含まれることになる
Web フロントエンドは JS のロード時間に影響するのでとても重要
最近は Tree Shaking される API を提供するライブラリが増えた
とはいえ、関数内の条件分岐など、それだけではカバーしきれないものもある
ライブラリから使わない実装を除いて自分で実装したらめちゃくちゃコード量が少なくなった、みたいなケースはたくさんある
ライブラリの作者が優秀とは限らない
自分で書いたほうが良い実装になることはよくある
Google の上位に来るライブラリが良いライブラリとは限らない
どうしてもライブラリを使いたい場合もあるだろう。実装する時間を短縮するために、ちょっとあやしいライブラリを使うことがあるかもしれない。そういった場合も、せめて腐敗防止層くらいは設けておくべきだ。将来そのライブラリを捨てることになったとしても、代わりのライブラリを入れたり、もしくは、自分で実装する場合のコストが大きく減る。
僕は UI コンポーネント集のようなライブラリには否定的だ。デザイナーの要求に答えられるような汎用性と表現力を持つものは無く、プロダクトの広範囲に依存をばらまく。実装も一つ一つは自分ですぐに作れるし、ライブラリの実装は過度に汎用的で複雑になっていて、バグを産みやすい。自分たちでそのプロダクトに最適な UI コンポーネント集を設計したほうが絶対にうまくいく。UI コンポーネント集を導入してうまくいくのは、デザイナーがいない（もしくは、デザイナーが諦めて UI コンポーネントに従うことにしている）、かつ、フロントエンドエンジニアが UI コンポーネントを設計できない場合だけだと思っている。