cockscomblog?

cockscomb on hatena blog

iOSアプリ開発における便利OSSライブラリの選定について

エッセー Development Cocoa iOS

f:id:cockscomb:20140506123733j:plain

(Andy Myers and the CocoaPods Dev team. Creative Commons - Attribution-NonCommercial 4.0 International)

iOSアプリを作るとき、今日ではCocoaPodsを用いて簡単に便利なライブラリの力を借りることができる。

ライブラリを利用するメリットは多い。自分でメンテナンスする必要がないので、放っておいても勝手に改善されていく。潜在的な問題があったとしても、多くの人が利用しているものなら誰かが気付いて直してくれる可能性も高い。また自分より優れたエンジニアの手によって、優れたインターフェースや実装になっているということも多い。何より、自分で実装する手間が省けるのがよい。

反面、デメリットについても考えなければならない。ライブラリがメンテナンスされなくなったとき、なにか問題が起こったり、あるいはAppleの気まぐれでコンパイルが通らなくなったらどうするのか。乗り換えるコストや、あるいは自分自身でメンテナンスすることを考慮する必要がある。またライブラリのインターフェースが全く変わってしまったら、これに対応するコストも必要である。リリースサイクルとの兼ね合いもある。

iOSアプリ開発においては、iOSが毎年大きなメジャーバージョンアップを繰り返すことや、言語仕様まで含めて開発環境が変わっていくことまで考慮しなければならない。もしアプリを一度リリースしてそれっきりで良いのなら何ら心配要らないだろう。しかし継続的なアップデートを数年にわたって続けていくつもりなら、無思慮なライブラリの選択はコードベースの寿命を縮める結果になりかねない。

ここで憚りながら、筆者のライブラリ選択の指針を公開する。参考になれば幸いである。

Effective Objective-C 2.0

Effective Objective-C 2.0

パラダイムを変えるようなライブラリは可能なら避ける

パラダイムを変えてしまうライブラリを利用すると、コードベースがライブラリと一蓮托生の運命を背負うことになる。パラダイムを変えるような大きなライブラリを利用することで、アプリケーション全体がそのライブラリと密になり、仮にそのライブラリが使えなくなったときアプリケーション全体にわたって変更が必要になる。実際的にはそのようなことはほとんど不可能である。もしそういったライブラリの何らかの機能をどうしても利用したいのであれば、その機能だけを小さく提供するライブラリを探してみる方が良いかもしれない。

インターフェースを確認する

ライブラリにおいて特に重要なのはインターフェースである。インターフェースは比較的変更しにくい。インターフェースが同じなら実装を変えるのは簡単だが、インターフェースが変わるときはそれを利用するコードも変えなければならない。またインターフェースが優れているとそれを利用するコードも良くなることが多い。利用したいライブラリのヘッダファイルをなるべく全て見ておく方が良い。

実装も見る

ライブラリがメンテナンスされなくなったときや、どうしても解決しないといけない問題があるとき、最終的には自分でなんとかする必要がある。そういったとき、実装が破滅しているとどうにも手を出せないかもしれない。また自分の実力の問題で理解できないということもあり得る。実装を確認して、最悪の場合は自分でどうにかできるようであると好ましい。

テストがあるライブラリは良いライブラリ

テストがあるライブラリは壊れにくい。またどうしてもなにか変更を加えたいとき、テストが通っていれば余計なところを壊していないことが確認できる。テストがないとこのような確認は困難であるから、テストがあるライブラリは良い。テストがないライブラリを使うときは警戒する必要がある。

開発がアクティブな方がずっと良い

開発が止まっているライブラリは不具合や環境の変化に対応されない。開発がアクティブなライブラリはそういったことに対応される上に、機能が向上していったりもする。コミットの頻度やリリースのタグの頻度などを確かめ、アクティブであるものを使った方が良い。

良いコードのライブラリを選ぶ

Objective-Cでは、例えばカテゴリで拡張されたメソッドにプリフィックスを付けるなどのコーディングルールがある。こういった規則を守っているか。あるいはそもそもカテゴリとして実装する必要があるのか、他のパターンでもっと良い設計にできるかもしれない。など、一般的に良いコードや設計になっているかどうかは必ず確かめておきたい。

依存が多いものは避けた方が無難

あるライブラリが依存している他のライブラリについても上記の注意事項は適用される。依存が多いものはその分だけリスクもある。

ここまで思いつく限りの注意事項を挙げた。ただ、これらの注意を全て満たすライブラリがそうそうあるとは思わない。それでも多くの場合は、手で丁寧に作るよりは既存の公開されているライブラリを利用する方がマシである。そういった中でどの部分を手で作り、あるいはライブラリを利用するのか、といった判断は我々に委ねられており、そこで賢明な選択をすることこそが肝要であろう。

いざライブラリがメンテナンスされなくなったとき、ライブラリを乗り換えるか、または自力で最低限のメンテナンスをしていくという選択肢がある。ライブラリを乗り換えようというとき、ライブラリを利用している箇所をアプリケーションの中で限定しておくと、影響が局所化されて良いかもしれない。またテストがあれば、乗り換えによって余計な箇所が壊れていないか確認しやすい。自力でメンテナンスを続けるときも、ライブラリにテストがあると安心であるし、無ければ最初にテストを書いておくと良いかもしれない。

iOSアプリ テスト自動化入門

iOSアプリ テスト自動化入門

ライブラリの選定について、様々な視点があることと思う。皆さまからのご意見を募集しています。

ご意見コーナー