はじめに
アプリ開発においてサードパーティのライブラリはとても心強い存在です。自分で1から実装すると何日も掛かるような機能を、ライブラリの導入により少ない工数で簡単に実現できます。結果的に浮いた工数は新しい機能の追加や改善、リファクタリングなどにも使うことができます。自分もこれまでにいくつものライブラリを選定し、多くのライブラリに助けられてきました。
そんな心強い存在であるライブラリなのですが、今までいくつものライブラリを選定してきて感じたのは”どうライブラリを選ぶか”というのはとても難しく悩ましい問題だということです。
プロダクトの性質、チームメンバー、既存のコードベースなど、ライブラリを選ぶために様々な要素を考慮する必要があります。さらにややこしいのは、得てして似たような目的で使うライブラリが複数あり、どれを選ぶか判断に迷うことが多いということです。
一方で選ぶ時間は限られています。せいぜい数十分〜数時間ぐらいでしょう。対して選んだライブラリと付き合う時間は思いのほか長い傾向があります。大抵のライブラリは一度導入すると簡単には外せないからです。プロダクトの性質にもよりますが、少なくとも数年ぐらいの付き合いにはなります。
つまり、選んだライブラリと付き合う時間は、ライブラリを選ぶ時間の数千倍以上にもなるのです。
もちろんコイントスか何かで適当に選ぶという手もあります。しかしプロダクトのビジネス的な側面においても、デザイン的な側面においても、そしてエンジニアリング的な側面においても、少しの積み重ねの差が時として圧倒的な差に繋がることがあります。ライブラリ選びというちょっとしたことでも、もし効率的で効果的な選び方があったとしたら、それをやらない手は無いのではないでしょうか？
ということで自分がライブラリを選ぶ時に気を付けているポイントをいくつか紹介したいと思います。
継続的にメンテナンスされているか
これは大抵の人が見ているポイントだと思うのですが、まずバグ系のissueやプルリクが溜まってないかを確認し、そのライブラリがメンテナンスされてるものかどうかを確認するのは重要です。
たとえスター数の多いライブラリでもすでにあまりメンテナンスされてない状態というのは結構あります。機能追加系のissueなどであれば問題ないのですが、何年も前のバク系のissueやプルリクが沢山Openになっているようであればよく検討した方がよいでしょう。実際にそのライブラリを導入した後、しばらくしてissueにあるようなややこいバクが再現して慌てて対応する必要に迫られることがあるからです。
そのような事にならないためにも基本的にメンテナンスされてないライブラリの採用はおすすめしませんが、そのライブラリを採用した場合どういう問題が起こる可能性があるかを知るためにも、一通りissueやプルリクを確認することをおすすめします。
実装がシンプルであるか
ライブラリ内部の実装がシンプルであるかどうか、というのも意外に重要なポイントです。
不具合調査やライブラリの仕様の確認などのため、ライブラリ内部の実装を把握する必要になることは決して珍しいことではありません。
内部の実装を把握するにあたり、実装がシンプルなものであればコードを読み解くのが容易になり、その分内部の実装も把握しやすくなります。対して実装が複雑なライブラリはその複雑さから大抵コードを読み解くのが容易ではなく、迅速な実装の把握を難しいものにします。
特に巨大なライブラリは得てして内部の実装が複雑になりがちです。自分が必要とする以上の機能をあまりに多く備えた巨大なライブラリを採用する場合は、必要とする機能を最小限実現するだけのミニマムなライブラリが他にないか探してみると良いかもしれません。
Swiftコードの比率
これもライブラリ内部の実装という観点なのですが、そのライブラリのコードがどの程度Swift(Objective-Cではなく)で作られたものなのか、というのもチェックした方が良いポイントです。
Swiftの登場以降、新機能や新規アプリ開発においては一部の例外的なケースを除いてObjective-CではなくSwiftを使うことがほとんどとなりました。また最近iOSアプリ開発を始める人のほとんどがObjective-CではなくSwiftで開発を始めます。傾向としてObjective-Cを使う機会がどんどん減ってきている & そもそもObjective-Cを使ったことが無い人が増えてきているのです。
そのためライブラリとの付き合いは数年程度にはなること & なんだかんだでライブラリ内部の実装を把握する必要が出てくることを考慮すると、使い慣れた人が減ってきているObjective-Cよりも、Swiftで多くの部分を書かれたライブラリがおすすめです。将来的にライブラリ内部の実装を把握する必要が出ても、使える人の多いSwiftで作られたライブラリであれば、そのプロジェクトに参加してる人のほとんどが理解できる言語なのでスムーズに実装を把握できるからです。
参考資料の多さ
そうあることではないのですが、もし巨大なライブラリを導入する場合、そのライブラリのドキュメントや解説記事が充実しているかどうかも気をつけるポイントです。
ミニマムなライブラリであればライブラリ内部の実装をざっくり確認すれば、そのライブラリの使い方や概念を理解できます。しかし巨大なライブラリとなると話は別で、コードベースが巨大な分、ドキュメントや解説記事無しでそのライブラリの使い方や概念をすぐに理解するのは難しいからです。
もちろん巨大なライブラリは導入しないに越したことはないのですが、一方で巨大なライブラリの力を借りる必要がある場合というのはどうしてもあります。その時、ライブラリについて参考にできる資料が多いことは、自分達にとっても、あるいはそのプロジェクトに後から参加することになった人達にとっても、大いにその助けとなるでしょう。
十分なテストコードがあるか
どんな種類のライブラリであれ十分なテストコードがあるライブラリの採用をおすすめします。ライブラリ自体ではなくそのテストコードを見るというのは意外かもしれませんが、これには上手にライブラリを選定する上でとても大きなメリットがあります。
まず十分なテストコードがあるということは、そのライブラリ自体が少なくともテストコードを書ける設計になっているということです。またテストコードが書きやすい設計かどうかも分かるので、そのライブラリが適切に設計されたものかを判断しやすくなります。
もしかするとなぜライブラリ内部の設計まで気にする必要があるのか？と思われるかもしれません。たしかに単にライブラリを使うだけなら、そのインターフェースが使いやすいものかだけを気にすれば良いのでしょう。
しかし冒頭でも述べたように、導入したライブラリとの付き合いは思いのほか長いものになります。その間、ライブラリがメンテナンスされなくなって自分たちがフォークしてメンテしていく必要になったり、あるいは自分たちのプロジェクトのためにライブラリをカスタマイズする必要になった、ということがどうしても出てきます。ライブラリを修正するにしろカスタマイズするにしろ、自分たちがそのライブラリのコードを読んで処理を把握して、それを変更する必要に迫られる可能性があるのです。
処理を把握しやすいコードか？変更しやすいコードか？はどういう設計になってるのかが大きく関わってきます。大抵の場合はテストコードが書けない(書きにくい)ような設計よりも、書ける(書きやすい)設計の方が処理も把握しやすくコードも変更しやすいものになります。そのためライブラリにテストコードがあれば、それを読むことで自分たちがコードを変更しやすい設計になっているかを判断しやすくなるのです。
そもそも外部のライブラリを導入すべきなのか
何も新たなライブラリを導入することが常に最適な選択とは限りません。新たにライブラリを導入しなくとも、普段iOSアプリ開発でよく使うSwiftの標準ライブラリやiOSのフレームワークに実現したい機能があるケースがあるからです。
Swiftの標準ライブラリやiOSのフレームワークは常に更新されています。それにより以前は無かった実現したい機能が最近になって標準でサポートされるようなことがあるのです。
例えば以前はJSONなどの任意のフォーマットを特定の型に変換する場合、それを簡単に実現する機能が標準で無かったため、ObjectMapperなどのサードパーティのライブラリを導入することが多くありました。しかし現在ではサードパーティのライブラリを導入しなくとも、Swiftの標準ライブラリとして新たに導入されたCodableなどにより、JSONを特定の型に簡単に変換できる機能を標準で使うことができます。
SwiftやiOSの標準でサポートされている機能は、SwiftやiOSが存在する限りはメンテナンス & 改善されます。そのためある程度の期間使われるようなアプリについては、標準でサポートされた機能を積極的に使うことに大きなメリットがあると思われます。新たにライブラリを導入する場合は、その実現したい機能と同じような機能がすでにSwiftやiOSで標準でサポートされてないか一度調べてみると良いかもしれません。
プロジェクトに合ったものか
ここまでライブラリ選びにおいて気をつけるポイントをいくつか上げましたが、最終的にはそのプロジェクトに合ったライブラリを選ぶ必要があります。どのライブラリが最適かはプロジェクトによって異なるからです。
プロダクトの性質によって最適なライブラリが変わってくることもあります。例えばいくらSwiftで作られたシンプルなライブラリであっても実現する必要のある機能が無ければ、代わりにObjective-C製の巨大でフルスタックなライブラリを選択肢に入れる必要があります。
またそのライブラリが既存のコードベースに合うのかや、自分以外のメンバーにとっても使いやすいものかどうかも考慮する必要があります。
今までに上げたポイントに加え、そのライブラリが自分たちのプロジェクトに合うものかどうかをトータルで考えることが重要になってくるのです。そういう意味ではこの点がライブラリ選びにおける一番の肝と言えるかもしれません。
まとめ
以上、自分が普段ライブラリを選定する時に見ているポイントをいくつか上げてみました。スター数以外にも見た方が良さそうなポイントが案外結構ありそうです。
何も意識せずにライブラリ選びをするとどうしてもスター数だけに目が行きがちですが、重要なのは一番人気のライブラリを選ぶことではなく、(自分たちのプロジェクトにとって)一番良いライブラリを選ぶことです。そのためにスター数以外にも様々な観点からそのライブラリを見ることをおすすめします。(もちろんスター数が多い=使ってる人が多い可能性が高いのでそれはそれで重要なポイントではあります)
というこで、この記事が少しでもその助けとなれば幸いです。