ライブラリやプラグインを使うときに気にしていること

アプリケーション開発において実装したい機能を実現するために、世の中に公開されているライブラリやプラグインを使ってフルスクラッチでの実装の手間を省くことがあります。その一方で、プラグインを理由にプラットフォームのアップデートを断念したり塩漬けにしているシーンをよく見かけました。

これまでJenkins、WordPress、Flutterとプラグインを選定する場面が多くあったなーと思っていて、知らず知らずのうちに自分の中での選び方の基準みたいなものができつつあったのでここで言語化しておこうと思います。

なお機能的な要件を満たすことは大前提となるのでここでは省きます。

1. 公式のプラットフォームで公開されていること

野良プラグインは怪しさ満点です。公式のマーケットプレイスで公開されているもの、さらに言えば公式が認めているもの（公式バッチがついている、メンテナーが企業になっている等）を使いましょう。

また実際にどう動いているのかソースが追えるようにGitHubでソース公開されているものを利用しましょう。

2. 評価が高く、利用実績が豊富であること

他の人も利用していて、かつ評価が高ければ、信頼度もあります。

3. ドキュメントが充実していること

2の裏返しかもしれませんが、ドキュメントがあると使いやすいですよね。

4. ライセンスの自由度が高いこと

MITやApache2.0など、再利用に関して自由度が高いものが法的リスクが低いです。

5. 更新が活発であること

プラグインが動作するプラットフォームや依存するソフトウェアに追従できていないと、あっという間に負債になってしまいます。

GitHubを見に行ってcommit数が順調に伸びていたり、Issueに対してきちんと対応されているかを見ましょう。

6. プラグインの内部のライブラリの依存リスクが明確になっていること

利用しているライブラリやプラグインが依存するものが大きいと、結局そこがボトルネックになってしまいます。

プラグインの中で依存するライブラリの中に、枯れたライブラリがないか目を通しておきましょう。

7. いざとなったら自分たちでメンテナンスできること

最終的に利用を続けるとなったときに、自分たちでパッチを充てたり修正していける内容なのかを見ましょう。

仮にそうだったとして、そのプラグインを使い続けるのか、余裕のあるときに自分で独自実装してしまうのかは再度立ち返って考えてみるといいと思います。

---

結局はソフトウェアのバージョンアップライフサイクルを考えたときに、それに依存するものを切り分けて、メンテナンス対象としてどう扱っていくかをきちんと考えよう ということなのだと思います。最近は言語やFWのバージョンアップライフサイクルは早く、1年も経てばあっという間に古くなってしまいます。

第三者の成果物を利用することは実装の手間を省くことができる一方で、時間が経ってから自分たちが取り扱えなくなったり依存関係によって更新できない負債と化すリスクもあるので十分注意しながら選定したいものです。