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

Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

Androidのプロダクトにguavaを入れたくない

雑に考えをまとめるので間違いがあったら教えてほしい。むしろguava入れたら最高だったけど?みたいな話があったら聞きたい。

guavaの何が嫌かといえば、一言で言えばその大きさである。便利そうなものがガッツリたっぷり入っている。まぁ実際便利だし、使いたいクラスもある。けどそれ以上にデメリットが大きいと感じてしまう。

デメリットの1つはアプリ自体のサイズの増加。メソッド数はproguardで削減できるとはいえ、ビルドの時間には影響するだろうなぁ嫌だなぁと感じてしまう。

もう1つはロックインの問題。guavaを導入したい理由はいろいろあると思うけれど、たぶんguavaのほんの一部の機能を使いたいだけってのがほとんどだと思う。自分は、それだけのためにguava入れて大丈夫?最初は軽い気持ちだったんです…みたいなことにならない?と不安に感じてしまう。

特にチームで開発する場合、guavaのような便利でマッチョなライブラリを入れてしまうと各人のコードにブレが生じがちだ。ある人はguava最高じゃんどんどん使うぞという思考で開発してくるかもしれないし、またある人はguavaはこの機能だけ使おうなみたいな認識でいるかもしれない。もちろんコード規約やチーム内の認識あわせで工夫できる部分ではあるけれど、意外と苦労する部分だったりする。そしてそういうブレのあるコードが一度マージされると、それを皮切りにしてどんどん統一感がなくなっていくこともある。

これはguavaに限った話ではなくて、ライブラリをどう選定するかという指針の話かもしれない。自分は何でもできるマッチョなライブラリは敬遠する傾向にある。用法用量を守って正しくお使いくださいという話ではあるのだけれど、経験上そういう指針を維持していくのはわりとコストがかかると感じている。便利なものを見つけたら喜んで使ってしまうのは人の常なのである。ライブラリは提示した課題をスマートに解決してるものがいい。余談だが、最近のButterKnifeはわりと太ってきたと感じることもある。

guava入れるなら、まずは何を解決したいのかを明確にしたい。そしてそれはguavaじゃないといけないのかをよく考えたい。正直、guavaじゃなくても自作できることが多いんじゃないかと思っているし、あるいはguavaの一部機能だけを切り出したライト版もいくつかあるので検討してもいいかもしれない。

余程の理由がない限り、guavaをプロダクトに導入したくない。